471,319 Members | 1,347 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,319 software developers and data experts.

Thread Communication in C#

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.
Jan 16 '06 #1
8 16432
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]
- mv*@spam.guard.caspershouse.com

"Jayme Pechan" <ja**********@whitefeld.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
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.

Jan 16 '06 #2
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.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:ez**************@tk2msftngp13.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Jayme Pechan" <ja**********@whitefeld.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
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.


Jan 16 '06 #3
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]
- mv*@spam.guard.caspershouse.com

"Jayme Pechan" <ja**********@whitefeld.com> wrote in message
news:ui**************@TK2MSFTNGP12.phx.gbl...
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.

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote
in message news:ez**************@tk2msftngp13.phx.gbl...
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]
- mv*@spam.guard.caspershouse.com

"Jayme Pechan" <ja**********@whitefeld.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
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.



Jan 16 '06 #4
Jayme Pechan <ja**********@whitefeld.com> wrote:
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/t...eadlocks.shtml
(Half way down the page.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jan 16 '06 #5
What about inverting your control somewhat. You could have a class for
each type of task, and have that class responsible for dispatching work
on the threadpool. Each class could then implement locking to prevent
multiple threads from working on the same task at the same time?


Jayme Pechan wrote:
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.

Jan 16 '06 #6
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
Jan 16 '06 #7
"Randy A. Ynchausti" <ra*************@msn.com> wrote in message
news:up**************@TK2MSFTNGP12.phx.gbl...
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
Jan 16 '06 #8

"Randy A. Ynchausti" <ra*************@msn.com> wrote in message
news:up**************@TK2MSFTNGP12.phx.gbl...
| 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.
Jan 16 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Ayende Rahien | last post: by
7 posts views Thread by Brett Robichaud | last post: by
9 posts views Thread by mareal | last post: by
6 posts views Thread by HolyShea | last post: by
12 posts views Thread by Ronny | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.