Thread Communication in C#

[Jayme Pechan]

I've been working on porting an application to C# that was previously
written in C++. This application is a windows service application so there
is no user interface. I have a number of worker threads in C++ that create
components and wait for messages from the main thread to process work. This
was all done using the PostThreadMessage and GetMessage. I recall that in
Unix I used to do this kind of thing with Pipes but I can't figure out how
to do this in C#. I need the thread to block until the main thread sends it
data to process and that is what the Pipes and GetMessage both did. Any
idea what is the correct way to duplicate this behavior in C# managed code?
Thanks.

 

[Nicholas Paldino [.NET/C# MVP]]

Jayme,

Well, if you want a completely managed solution, I would use a
ManualResetEvent, which is tailored for the thread. This will work only if
you have a handful of messages you send to each thread (start, stop, for
example), because you would have to send a different event for each message,
and wait on those.

You can also make the same calls to GetMessage and PostThreadMessage if
you wish, making the calls through the P/Invoke layer.

Hope this helps.

 

[Nicholas Paldino [.NET/C# MVP]]

Jayme,

If this is the case (you need to send data with the message), then just
use the GetMessage and PostThreadMessage functions. You can find the
declarations at http://www.pinvoke.net.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

If I use ManualResetEvent, I still need some way to pass data between the
two threads. I guess I could create a queue for each thread but I'm not
sure how to pass the reference to the queue to the sub thread at start. I
thought about making it a static queue but the data must be directed to
the right thread. Any thoughts on how to get past this hurdle? Thanks
for your help.

Jayme,

Well, if you want a completely managed solution, I would use a
ManualResetEvent, which is tailored for the thread. This will work only
if you have a handful of messages you send to each thread (start, stop,
for example), because you would have to send a different event for each
message, and wait on those.

You can also make the same calls to GetMessage and PostThreadMessage
if you wish, making the calls through the P/Invoke layer.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I've been working on porting an application to C# that was previously
written in C++. This application is a windows service application so
there is no user interface. I have a number of worker threads in C++
that create components and wait for messages from the main thread to
process work. This was all done using the PostThreadMessage and
GetMessage. I recall that in Unix I used to do this kind of thing with
Pipes but I can't figure out how to do this in C#. I need the thread to
block until the main thread sends it data to process and that is what
the Pipes and GetMessage both did. Any idea what is the correct way to
duplicate this behavior in C# managed code? Thanks.

 

[Jayme Pechan]

If I use ManualResetEvent, I still need some way to pass data between the
two threads. I guess I could create a queue for each thread but I'm not
sure how to pass the reference to the queue to the sub thread at start. I
thought about making it a static queue but the data must be directed to the
right thread. Any thoughts on how to get past this hurdle? Thanks for your
help.

Jayme,

Well, if you want a completely managed solution, I would use a
ManualResetEvent, which is tailored for the thread. This will work only
if you have a handful of messages you send to each thread (start, stop,
for example), because you would have to send a different event for each
message, and wait on those.

You can also make the same calls to GetMessage and PostThreadMessage if
you wish, making the calls through the P/Invoke layer.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I've been working on porting an application to C# that was previously
written in C++. This application is a windows service application so
there is no user interface. I have a number of worker threads in C++
that create components and wait for messages from the main thread to
process work. This was all done using the PostThreadMessage and
GetMessage. I recall that in Unix I used to do this kind of thing with
Pipes but I can't figure out how to do this in C#. I need the thread to
block until the main thread sends it data to process and that is what the
Pipes and GetMessage both did. Any idea what is the correct way to
duplicate this behavior in C# managed code? Thanks.

 

[Jon Skeet [C# MVP]]

I've been working on porting an application to C# that was previously
written in C++. This application is a windows service application so there
is no user interface. I have a number of worker threads in C++ that create
components and wait for messages from the main thread to process work. This
was all done using the PostThreadMessage and GetMessage. I recall that in
Unix I used to do this kind of thing with Pipes but I can't figure out how
to do this in C#. I need the thread to block until the main thread sends it
data to process and that is what the Pipes and GetMessage both did. Any
idea what is the correct way to duplicate this behavior in C# managed code?

I'd suggest using some variation on a producer/consumer queue (which is
basically what the message queue is). See
http://www.pobox.com/~skeet/csharp/threads/deadlocks.shtml
(Half way down the page.)

 

[John Murray]

What about inverting your control somewhat. You could have a class for
each type of task, and have that class responsible for dispatching work

 

[Randy A. Ynchausti]

Jayme,

I've been working on porting an application to C# that was previously
written in C++. This application is a windows service application so
there is no user interface. I have a number of worker threads in C++ that
create components and wait for messages from the main thread to process
work. This was all done using the PostThreadMessage and GetMessage. I
recall that in Unix I used to do this kind of thing with Pipes but I can't
figure out how to do this in C#. I need the thread to block until the
main thread sends it data to process and that is what the Pipes and
GetMessage both did. Any idea what is the correct way to duplicate this
behavior in C# managed code?

One way to do this is through the use of delegates. Just after the threads
are created pass a delegate for posting messages to the service and retrieve
a delegate to post a message to the thread, etc. Each thread of the service
would then be responsible for posting messages to the service and for
managing the messaging that are sent to it.

The other way I can imagine to acheive this is to implement custom commands
on the service. This has the advantage of exposing the messaging capability
through the service control manager. That could rather be a weakness
instead. It depends on your perspective.

Regards,

Randy

 

[Alan Pretre]

One way to do this is through the use of delegates. Just after the
threads are created pass a delegate for posting messages to the service
and retrieve a delegate to post a message to the thread, etc. Each thread
of the service would then be responsible for posting messages to the
service and for managing the messaging that are sent to it.

I like this. Even further, I was privately wondering to myself, if these
are one-way messages why not use .NET events?

-- Alan

 

[Willy Denoyette [MVP]]

| Jayme,
|
| > I've been working on porting an application to C# that was previously
| > written in C++. This application is a windows service application so
| > there is no user interface. I have a number of worker threads in C++
that
| > create components and wait for messages from the main thread to process
| > work. This was all done using the PostThreadMessage and GetMessage. I
| > recall that in Unix I used to do this kind of thing with Pipes but I
can't
| > figure out how to do this in C#. I need the thread to block until the
| > main thread sends it data to process and that is what the Pipes and
| > GetMessage both did. Any idea what is the correct way to duplicate this
| > behavior in C# managed code?
|
| One way to do this is through the use of delegates. Just after the
threads
| are created pass a delegate for posting messages to the service and
retrieve
| a delegate to post a message to the thread, etc. Each thread of the
service
| would then be responsible for posting messages to the service and for
| managing the messaging that are sent to it.
|
| The other way I can imagine to acheive this is to implement custom
commands
| on the service. This has the advantage of exposing the messaging
capability
| through the service control manager. That could rather be a weakness
| instead. It depends on your perspective.
|
| Regards,
|
| Randy
|
|

The OP is asking about in-process cross-thread message passing, not
cross-process.
The best solution for this is a producer/consumer queue as Jon proposed,

Willy.