What is the C# equivalent of GetMessage ????

[Guest]

Hi,

I am tring to pass messages between threads, using the good old C++ I would call the GetMessage/PostThreadMessage APIs, Now, I am using C# and i can't find any equivalenty for these calls, any Idea how to communicate between threads and access the threads message queue will be appriciated...

 

[Niki Estner]

These were user interface APIs, not thread communication APIs. The
"System.Windows.Forms.Control.Invoke" function wraps them in a clean,
object-oriented fashion (the message loop is wrapped in the Application
class IIRC).
Don't use them for communication between non-UI threads. Use pipes,
sychnronization objects, locks, events & friends for that purpose. If
anybody will ever have to find a bug in your code, she will definitely
appreciate that!

Niki

 

[Guest]

Hi Niki, Thanks for your response, Still, I didn't understand from your response if there is an equivalent for the threads message queue management Win32 API, there must be a .NET class for the threads message queue management, Thread message queue management is an elementary feature in inter thread communication and i find it hard to believe that the .NET framework doesn't support the inter-thread communication in this way, Still, I couldn't find any equivalent to the Win32 message queue equivalents ( e.g. GetMessage, PostThreadMessage, ... ).
--
Nadav
http://www.ddevel.com

These were user interface APIs, not thread communication APIs. The
"System.Windows.Forms.Control.Invoke" function wraps them in a clean,
object-oriented fashion (the message loop is wrapped in the Application
class IIRC).
Don't use them for communication between non-UI threads. Use pipes,
sychnronization objects, locks, events & friends for that purpose. If
anybody will ever have to find a bug in your code, she will definitely
appreciate that!

Niki

 

[Jon Skeet [C# MVP]]

Hi Niki, Thanks for your response, Still, I didn't understand from
your response if there is an equivalent for the threads message queue
management Win32 API, there must be a .NET class for the threads
message queue management, Thread message queue management is an
elementary feature in inter thread communication and i find it hard
to believe that the .NET framework doesn't support the inter-thread
communication in this way, Still, I couldn't find any equivalent to
the Win32 message queue equivalents ( e.g. GetMessage, PostThreadMessage,
... ).

Interthread communication shouldn't use the Win32 message queue unless
it's UI-related, I thought - in which case you can use Control.Invoke
etc.

For other situations where there aren't UI controls or where you don't
want to go to the UI thread, you can easily set up your own message
queue.

See
http://www.yoda.arachsys.com/csharp/multithreading.html#monitor.methods

for a very simple example of such a queue. (In practice you'd want a
way of stopping the queue etc.)

 

[Guest]

And why exactly the Win32 message queue shouldn't be used for inter-thread communication??????

 

[Jon Skeet [C# MVP]]

And why exactly the Win32 message queue shouldn't be used for
inter-thread communication??????

For one thing, because only threads associated with controls will be
pumping messages, at least in .NET, as far as I can tell.

 

[Guest]

And why exactly the Win32 message queue should ONLY be used for UI Threads?????

 

[Jon Skeet [C# MVP]]

And why exactly the Win32 message queue should ONLY be used for UI
Threads?????

Look at the docs for PostMessage, PostThreadMessage, GetMessage etc.
They're full of references to UI concepts. To me, it's far cleaner to
create a queue of messages which has *nothing* to do with UI, and use
methods which also have nothing to do with UI (Monitor.Wait/Pulse etc).

 

[Jon Skeet [C# MVP]]

That?s right as for the .NET Framework, BUT, I wonder, when creating
a custom thread, is there any special reason not to use the thread
queue??? My guess is that when creating windows from a thread the
thread must provide a message pump, sending custom messages to a
thread requires integration with the current message pump.. the only
reason that custom messages cannot be used in a non UI thread must be
Poor implementation of the .NET Framework, Win32 has no
such limitation, in fact inter thread messages are commonly used while
developing multi-threaded applications using Win32 API.

Is my assumption is true? is there any other reason?

I don't think it's a poor implementation of the .NET framework at all.
Perhaps it would be nice if MS had provided something which would be a
sort of message queue, but it's far from difficult to do manually.
Disconnecting it from the Win32 message queue seems like a good idea to
me - as I've pointed out in another post, there are all kinds of UI
relationships involved in the Win32 message queue which have no
business being in a general purpose inter-thread message queue, in my
view.

 

[Scott Allen]

Tell that to the COM team, where synchronization of single threaded
apartment objects relied on a hidden window and message pump

Of course, COM was providing the plumbing for environments like VB,
where thread management and synchronization functionality wasn't baked
into the runtime.

 

[Jon Skeet [C# MVP]]

Tell that to the COM team, where synchronization of single threaded
apartment objects relied on a hidden window and message pump

Of course, COM was providing the plumbing for environments like VB,
where thread management and synchronization functionality wasn't baked
into the runtime.

Exactly. We have perfectly reasonable threading now with no need to
reference UI components at all.

 

[Roy Fine]

Jon

the only UI concepts in Win32 threading is the WM_PAINT message - it is a
low priority message that is handled internally by the kernel, and is
dispatched when the queue is empty, and only after a flag has been set -
typically by the Invalidate API method. WM_TIMER is similar, but there is
no UI concern whatsoever. More appropriately, there are a lot of UI
concepts that are implemented using the Win32 Thread Message Queue. In the
absence of a window, you would use the PostThreadMessage, and specify the
thread id instead of the familar HWND. A much more acceptable approach
would be to create a message only window - hWndParent HWND set to
HWND_MESSAGE (still no UI stuff here), and then revert to the PostMesssage
that we are all so comfortable with, using the familar HWND.

A much stronger case for not using the Win32 thread message queue for
multithread comminucation and synchronization is the enormous overhead -
especially with the high number of kernel mode calls that are made - esp
PostMessage, GetMessage, and DispatchMessage - all of which can easily be
implemented using a simple queue object that exists entirely in the
application/process address space, and a CRITICAL_SECTION which requires a
kernel mode call only for the wait if the CS has been acquired - see Matt
Pietrek's excellent article Dec 2003...

That said, using the Win32 thread message queue for multithreading work is
quite acceptable - because it is available for use, well documented, and
very robust - albeit just not available in .Net yet (so the whole lot
quickly distills down to a moot point - much like discussing the rework of
the foreach statement).

regards
roy fine

 

[Jon Skeet [C# MVP]]

the only UI concepts in Win32 threading is the WM_PAINT message

Really? In that case, why are the docs spattered with references to
windows? Sure, you can have invisible windows, but that's a hack, IMO -
there shouldn't be any need for it, or any reference to windows in
straight threading.

- it is a
low priority message that is handled internally by the kernel, and is
dispatched when the queue is empty, and only after a flag has been set -
typically by the Invalidate API method. WM_TIMER is similar, but there is
no UI concern whatsoever. More appropriately, there are a lot of UI
concepts that are implemented using the Win32 Thread Message Queue. In the
absence of a window, you would use the PostThreadMessage, and specify the
thread id instead of the familar HWND. A much more acceptable approach
would be to create a message only window - hWndParent HWND set to
HWND_MESSAGE (still no UI stuff here), and then revert to the PostMesssage
that we are all so comfortable with, using the familar HWND.

I don't think that *is* acceptable - because it's conflating the idea
of a window, which is a UI concept, even if it's then only used for
messages and is never made visible, and threading. Why *should* a
threading system use windows as the "more acceptable" approach? Does
that concept appear in other operating systems? (I genuinely don't know
the answer to that one.)

Even PostThreadMessage isn't UI-free - the docs talk about what desktop
the thread belongs to!

Furthermore, I regard the PostThreadMessage (and GetMessage etc) APIs
as somewhat non-OO. In my experience, it's cleaner to not know which
thread you're actually posting a message to, but only which *queue*
you're posting a message to - then it's very easy to add more threads
servicing the same queue. A message should also be a proper object,
rather than two integers with one of them split in half.

A much stronger case for not using the Win32 thread message queue for
multithread comminucation and synchronization is the enormous overhead -
especially with the high number of kernel mode calls that are made - esp
PostMessage, GetMessage, and DispatchMessage - all of which can easily be
implemented using a simple queue object that exists entirely in the
application/process address space, and a CRITICAL_SECTION which requires a
kernel mode call only for the wait if the CS has been acquired - see Matt
Pietrek's excellent article Dec 2003...

Right - I'll look that out.

That said, using the Win32 thread message queue for multithreading work is
quite acceptable - because it is available for use, well documented, and
very robust - albeit just not available in .Net yet (so the whole lot
quickly distills down to a moot point - much like discussing the rework of
the foreach statement).

I don't think it's a moot point - I think there's significant design
discussion to be had here.

 

[Roy Fine]

"Jon Skeet [C# MVP]"

I don't think that *is* acceptable - because it's conflating the idea
of a window, which is a UI concept, even if it's then only used for
messages and is never made visible, and threading. Why *should* a
threading system use windows as the "more acceptable" approach? Does
that concept appear in other operating systems? (I genuinely don't know
the answer to that one.)

Even PostThreadMessage isn't UI-free - the docs talk about what desktop
the thread belongs to!

here you go again with that bull-headed attitude - adopt an idea, and then
kill off all that cant accept it. The desktop is a security object not a
user interface object! reads the docs please - look at enum desktops. it
looks at all desktops in a specific windows stations. wndsta is not a UI
related object, and only ONE desktop in winsta0 is a UI related object. If
one takes your position to the extreme, then everything in the Windows
operating system is UI related, because is has the name Windows in it.

if you think a message-only window is a conflation of UI and non-UI, you
again miss the point. the message-only window has all of the things that we
are looking for - the message pump mechanism (GetMessage - DispatchMessage)
and it takes you one step above the thread - now you have process scope for
you message passing.

what other operating systems offer the threading model as Windows, you ask?
I don't think that should be allowed in here, as it just confuses the issue.
start another thread

Furthermore, I regard the PostThreadMessage (and GetMessage etc) APIs
as somewhat non-OO. In my experience, it's cleaner to not know which
thread you're actually posting a message to, but only which *queue*
you're posting a message to - then it's very easy to add more threads
servicing the same queue. A message should also be a proper object,
rather than two integers with one of them split in half.

nice change of subject -- we are talking UI, and now you want to argue
vis-a-vis OO. but to argue that to know which thread versus which queue is
missing the point - you post to a thread id when using the thread message
queue - else you post to some other object, identified by some other handle
when using some other queuing mechanism - from an abstract, conceptual point
of view, they are soooo very close, the distinction is hard to see.

Right - I'll look that out.


I don't think it's a moot point - I think there's significant design
discussion to be had here.

again, you miss the point jon. arguing the merits of using the thread
message queue versus some other queuing mechanism IS a moot point in this
NG. in >Net, you do not have to consider the thread message queue.

regards
roy

 

[Jon Skeet [C# MVP]]

here you go again with that bull-headed attitude - adopt an idea, and then
kill off all that cant accept it. The desktop is a security object not a
user interface object! reads the docs please - look at enum desktops. it
looks at all desktops in a specific windows stations. wndsta is not a UI
related object, and only ONE desktop in winsta0 is a UI related object.

And that's just another annoying conflation, in my view. Why give a UI
desktop and a security object the same model? A UI desktop should no
doubt *have* a related security object, but conflating the two was a
mistake. Again, just my opinion.

Another way in which PostThreadMessage is UI-related is described in
the docs though: if the thread to which the message is posted is in a
modal loop, the message will get lost. That hardly seems like a good
idea - you need to know details about the thread you're posting a
message to in order to guarantee delivery. Just another reason to use
an API which posts a message to a queue rather than to a thread - then
any appropriate thread can pick up the message, whether that's by
pumping or some other mechanism.

If one takes your position to the extreme, then everything in the Windows
operating system is UI related, because is has the name Windows in it.

There are plenty of APIs which don't refer to windows (or any other UI
element).

if you think a message-only window is a conflation of UI and non-UI, you
again miss the point. the message-only window has all of the things that we
are looking for - the message pump mechanism (GetMessage - DispatchMessage)
and it takes you one step above the thread - now you have process scope for
you message passing.

But the way things *should* be built, IMO, is to have a mechanism which
has nothing to do with the UI but which has message pumping (of a more
general kind, preferably of

what other operating systems offer the threading model as Windows, you ask?
I don't think that should be allowed in here, as it just confuses the issue.
start another thread

I don't think it confuses the issue at all - I think it shows that the
idea that threads and UI should always be related is probably not a
good one.

nice change of subject -- we are talking UI, and now you want to argue
vis-a-vis OO.

It's not a change of subject at all. The OP wanted to know how to use
GetMessage because he wanted to do cross-thread communication. The non-
OO nature of Windows messages is another reason not to use
GetMessage/PostMessage and instead to use a more .NET-friendly way.

but to argue that to know which thread versus which queue is
missing the point - you post to a thread id when using the thread message
queue - else you post to some other object, identified by some other handle
when using some other queuing mechanism - from an abstract, conceptual point
of view, they are soooo very close, the distinction is hard to see.

And that handle has to be a window, right? If there's no window
*logically* needed, why use a mechanism which introduces it when
there's a perfectly good mechanism which *doesn't* introduce it?

again, you miss the point jon. arguing the merits of using the thread
message queue versus some other queuing mechanism IS a moot point in this
NG. in >Net, you do not have to consider the thread message queue.

The OP wants inter-thread communication. Whether to use P/Invoke to use
a Win32 message queue or whether to use a more OO, non-UI-related API
is far from a moot point. Both are feasible ways of working, but I'm
trying to give reasons why a message queue independent of the Win32
message queue is a good idea.