[Q] Threads or events - How to?

[stuie_norris]

Hi Readers,

I am trying to understand threading and or evetns with C#.

So I have set myself up a learning challenge.

I wish to develop and application that reads information
asynchronously using TCP sockets and uses a seperate
thread to process data once it has arrived. This second thread, a
logger thread, will log data to a file and
using delegates update the GUI thread if required.

So I have essentially three threads GUI, logger and the self
propogating TCP thread.

The self progating TCP thread uses socket.BeginReceive and to
constantly receive data from the TCP stream.
This thread just reads the data in inserts into a global variable
arraylist and then calls the socket.BeginReceive
method again. Yes I lock the Arraylist whilst inserting the data.....

At the moment I have my logger thread just sleep and wake up every
second to see if there is any data in
the global arraylist from the TCP reads to process. Again I lock the
array list to read the data.

This is pretty inefficient and pretty poor programming, so I wish to
modify my program to somehow have the TCP
thread, which knows the name of the logger thread and the arraylist to
WAKE the logger thread if there is data
to process.

The reason for all this is to keep my GUI thread really responsive.

Here comes the confusion:

I want to have the logger thread wait for the trigger from the TCP
thread. Whilst the logger process is
waiting for the trigger it should use zero CPU (hibernate). Also once
the logger thread has processed all
the data from the arraylist should again hibernate / wait until TCP
thread triggers the logger thread again.

I do not want the logger thread to use any CPU until it receives the
trigger from the TCP thread as it is
pointless to have the logger thread constantly looking into the
Arraylist.

I come from an OpenVMS background and this can be efficiently
implemented using event flags.

So should I use threads for this or should I use events for this? Any
suggestions most welecome?????

I wish to learn the best way so I can continue to expand my program
and learn more about C# and windows programming.

Thanks

Stuart

 

[Peter Duniho]

[...]
I do not want the logger thread to use any CPU until it receives the
trigger from the TCP thread as it is
pointless to have the logger thread constantly looking into the
Arraylist.

I come from an OpenVMS background and this can be efficiently
implemented using event flags.

So should I use threads for this or should I use events for this? Any
suggestions most welecome?????

The two are not mutually exclusive.

What you want is an event, not an event.

Clear?

Win32 has the idea of an "event" that is like the VMS event flag you're
used to. A thread can wait for an event to be signaled, proceeding only
when it is.

This is different from the .NET concept of an "event", this construct that
allows delegates to be added and removed and which can be executed at
appropriate times.

It's the former you want, and it will work just as you'd like. You create
the event, your logger thread will wait on the event, the TCP thread will
add whatever it wants to the logger's queue and then signal the event,
releasing the logger thread for processing, at which point the logger
thread would just go through and process everything it finds in its queue.

Hope that helps.

Pete

 

[William Stacey [C# MVP]]

I think your looking for a producer/consumer pattern. This is a pretty
common and powerful pattern. There are many variations, but common way is a
blocking queue. You can hand off message to a queue. On the consumer side
of the queue, another thead blocks waiting for items. When it gets an item,
it does work. This may help:
http://channel9.msdn.com/ShowPost.aspx?PostID=50960#50960

--
William Stacey [C# MVP]
PCR concurrency library: www.codeplex.com/pcr
PSH Scripts Project www.codeplex.com/psobject


| Hi Readers,
|
| I am trying to understand threading and or evetns with C#.
|
| So I have set myself up a learning challenge.
|
| I wish to develop and application that reads information
| asynchronously using TCP sockets and uses a seperate
| thread to process data once it has arrived. This second thread, a
| logger thread, will log data to a file and
| using delegates update the GUI thread if required.
|
| So I have essentially three threads GUI, logger and the self
| propogating TCP thread.
|
| The self progating TCP thread uses socket.BeginReceive and to
| constantly receive data from the TCP stream.
| This thread just reads the data in inserts into a global variable
| arraylist and then calls the socket.BeginReceive
| method again. Yes I lock the Arraylist whilst inserting the data.....
|
| At the moment I have my logger thread just sleep and wake up every
| second to see if there is any data in
| the global arraylist from the TCP reads to process. Again I lock the
| array list to read the data.
|
| This is pretty inefficient and pretty poor programming, so I wish to
| modify my program to somehow have the TCP
| thread, which knows the name of the logger thread and the arraylist to
| WAKE the logger thread if there is data
| to process.
|
| The reason for all this is to keep my GUI thread really responsive.
|
| Here comes the confusion:
|
| I want to have the logger thread wait for the trigger from the TCP
| thread. Whilst the logger process is
| waiting for the trigger it should use zero CPU (hibernate). Also once
| the logger thread has processed all
| the data from the arraylist should again hibernate / wait until TCP
| thread triggers the logger thread again.
|
| I do not want the logger thread to use any CPU until it receives the
| trigger from the TCP thread as it is
| pointless to have the logger thread constantly looking into the
| Arraylist.
|
| I come from an OpenVMS background and this can be efficiently
| implemented using event flags.
|
| So should I use threads for this or should I use events for this? Any
| suggestions most welecome?????
|
| I wish to learn the best way so I can continue to expand my program
| and learn more about C# and windows programming.
|
| Thanks
|
| Stuart
|