Comment Feed for Threading woes (TechOff on Channel 9)

Re: Re: Re: Threading woes

Minh — Mon, 21 Jul 2008 14:34:27 GMT

phreaks said:

I have also read that BeginRead isn't "really" asynchronous.

From the comments of that blog post, it seems that it's a CLR 1.x problem. Plus there's a work-around by checking the CompletedSynchronously prop to avoid a stack overflow.

What framework are you on?

Re: Re: Re: Re: Re: Threading woes

figuerres — Mon, 21 Jul 2008 01:08:03 GMT

Ok you need a "watchdog" that can re-start the tcp connection, that should be ok.

and I would still spin off a worker to read the data, and fire some kind of "got data" event.

your DoWOrk can run the watchdog and if no datarecived in xx time then do a re-set and re-start of the tcp connection.

service control is handled the way I outlined before.

just that you get the read/write/ TCP/IO on a seperate thread .... Hmmm perhaps 2 bgw processes?? one for TCP and the other for SCM??

that way your TCP data can be read and processed asnyc from any SCM state.

but the SCM worker can tell the TCP worker to stop /restart/exit.

I do not have my TCP/Networking book handy at home to check on the details.

Re: Re: Re: Re: Threading woes

phreaks — Sun, 20 Jul 2008 23:06:14 GMT

Yeah, you mostly understand what I need, but there is one small caveat.

I am not spinning up new TCP connections, doing some work and then killing the connection.

I am spinning up a persistant connection to a server that will generally be receiving data perpetually. However, there can and will be periods when the server may not transmit any data for minutes or possibly even an hour.

I have to authenticate with the server, and it only allows 1 active connection with my credentials.

So I need to handle
1) When the service receives a stop/reset/pause command
2) When the there has been no activity from the server for x period, shutdown the socket for a few minutes (the server will que any data I mised for an hour) and start listening again.

The real problem is that sometimes there is an error on the server and it doesn't abort the connection, it just stops sending data. So I want to reset the TCP connection every hour.

Do you think your approach will still work?

Re: Re: Re: Threading woes

figuerres — Sun, 20 Jul 2008 22:27:13 GMT

Not sure If I am following this so let me know if I have it wrong.

you are needing to read some data from a remote server yes?

so then you should setup the request to be serviced on an async worker that when it completes will notfiy your serive that the request has been completed

your DoWOrk should kick off the worker and then go back to a sleep loop.

when it wakes up if it then needs to do something it does.

if your worker can process the data it does that before it dies if it's a one shot call.
then your service can get a stop command from scm and if it has to it can terminate the workers as needed.

you do not start a long runing / blocking task on your main service loop.

if you look at code for unix deamons for example you will see they do a set of fork and spawn commands to branch off into multiple thread / process /task depdneding on which version of UNIx / Linux/ BSD etc... they are.

sounds kind of sick but the parents sit around waiting for the children to die.

Re: Re: Re: Re: Threading woes

phreaks — Sun, 20 Jul 2008 21:17:54 GMT

What do you mean?

Is there an easier way?

PS..
You're avatar is broken on every other load.

Re: Re: Re: Threading woes

stevo_ — Sun, 20 Jul 2008 20:57:34 GMT

Yes the read probably is blocking and causing the problem, but I wondered why you were recreating the wheel really..

Re: Re: Threading woes

phreaks — Sun, 20 Jul 2008 20:30:50 GMT

Dexter is right.

BackgroundWorker isn't going to work for me because it is the read method that's blocking, and that is where my headache starts.

The Server will only allow 1 connection, so I have to be very careful how I close and initiate a connection.

I have reservations though with using BeginRead because as I understand it, I can't be guaranteed the order that the stream is read, which means I can't save it in the correct order.

I have also read that BeginRead isn't "really" asynchronous.

I think I am stuck.

Re: Re: Re: Threading woes

phreaks — Sat, 19 Jul 2008 21:37:33 GMT

Sweet dude.

I will try this.

Re: Re: Threading woes

figuerres — Sat, 19 Jul 2008 21:23:29 GMT

Guys, I have used BGW in multiple service projects and it rocks! works super sweet!!

in general what I do is this:

OnStart calls RunWOrkerAsync
OnStop / ReStart set the cancel flag of the BW
the DoWork gets a setup like this:

While( !CancelFlag && !ExitFlag){
Dosomething();
Sleep(timeout);
}

where the sleep time needs to be less than 30 seconds to work with scm and respond in time.

the "dosomething()" is the part that needs to be custom for each service and may test and exit fast if nothing needs to be done.
as you are doing tcp/ip you may want to also setup a thread pool also to do the actual netowork stuff.
keep the DoWOrk() as a main controller and dispatcher

so for example it listens and when a new message / connection happens you spin up a new worker thread to handle it. that way the main worker / DoWOrk keeps ready to handle more dispatching of work.

Re: Re: Threading woes

phreaks — Sat, 19 Jul 2008 18:08:19 GMT

Thanks.

This is very helpful.

Re: Threading woes

Dexter — Sat, 19 Jul 2008 17:45:58 GMT

I'd be a bit careful about using BackgroundWorker in a service application. While it works its behavior is different from the one you get in a WinForms application, for example its ReportProgress notification will go on a thread from the thread pool rather than the main thread.

In any case, it still relies on the worker thread checking a value to see if "cancel" was request (CancellationPending property) and we're back to square one. The most likely reason why it takes a while for that thread to stop is NetworkStream.Read. Read is a blocking call, if there's no data available it just sits there waiting so your _stopRequested variable will only be checked when the server sends something.

A simple workaround would be to set a reasonable ReadTimeout, 100 ms for example.
A brutal aproach would be to either abort the worker thread or close the socket from the main thread.
A more complex solution would be go async by using BeginRead instead of Read which avoid the blocking.

Re: Re: Re: Re: Threading woes

phreaks — Sat, 19 Jul 2008 17:01:43 GMT

Thanks, I'll check it out.

Re: Re: Re: Threading woes

stevo_ — Sat, 19 Jul 2008 16:36:31 GMT

Its often used for UI to keep the UI thread ready, but I think the technical design for it is to help with the problem you have above.. it wraps a thread and provides built in functionality for calling back the complete method on the right thread, and being able to push cancellations in from other threads, yadda yadda.

Re: Re: Threading woes

phreaks — Sat, 19 Jul 2008 16:20:00 GMT

Well, honestly, I dunno. I've never used a background worker.
For some reason I thought that was for synching with a UI, and my service has no UI.

Re: Threading woes

stevo_ — Sat, 19 Jul 2008 16:10:24 GMT

Just quickly, before I analyse your code, why aren't you using BackgroundWorker? it handles the thread sync for calling back completion and handles doing pending cancellations etc.