|Subject:||Re: [OT] WMQ and threading|
|Posted by:||Martin James (mjames_falc…@dial.pipex.com)|
|Date:||Thu, 27 Oct 2005|
> After reading (a while back) the messages about using the WMQ for P/C
> it got my curiosities up. I started taking the code I was working on for
> generic P/C Queue and converting it to use the WMQ as the transport mech.
> This brings up a question that I can't seem to find a definate answer to
> default is the WMQ thread safe".
Yes- that't the whole point.
Let me clarify my question as I know it
> sounds ignorant :). When calling post or send does windows handle the
> locking behind the scenes or do you have to perform the locking yourself?
Just call PostMesage or PostThreadMessage from as many threads as you like.
Only the one thread that created the message queue willl serially get the
> Reading obviously requires locking long enough to pop the message off the
> stack and compressing the stack (as well as updating the Pool). But how
> about the actual post :).
Not a problem.
There are some problems with WMQ, but explicit locking on post is not one of
The WMQ only allows a single consumer thread to wait on it - the one that
created it. This makes thread pooling, where many threads wait on one queue
for work, 'very difficult' <g>
GetMessage has no timeout. To some extent, this is mitigated by Windows
timers.and their messages, but it's messy.
WMQ are somewhat specialised and, presumably as a result of the extra code,
slow for communicating single 32-bit object references.
[OT] WMQ and threading posted by Jeremy Darling on Tue, 25 Oct 2005