Can multiple processes communicate through Message Queues or is it only for multiple thread communication ? I want to let two different processes communicate. I don t want to use shared memory because of some reasons. I want to use message queues instead. Is is doable ?
Yes, this is possible. Call the PostMessage function to add a message to the queue for a window, or PostThreadMessage to add a message to the queue for a thread. (Obviously, the thread must be running a message loop.)
The WM_COPYDATA message is explicitly designed for this purpose. It does the marshaling for you. Of course, it is a pretty basic form of marshaling: all it knows how to do is marshal a blob of bytes. It's your responsibility to interpret that blob of bytes into something useful.
There is a complete example of copying data between processes here on MSDN.
It is also worth pointing out that you don't even need WM_COPYDATA if the amount of information that you want to pass is so small that it will fit inside of wParam or lParam.
The Message Queing is a construct for inter process communication (IPC).
You can build a data construct in the memory of one process that even can implement a queue. This can be use for quick processing e.g. for Windows messages. This must be differentiated from MSMQ.
Related
We need to build a software framework (or middleware) that will enable messaging between different software components (or modules) running on a single machine. This framework will provide such features:
Communication between modules are through 'messaging'.
Each module will have its own message queue and message handler thread that will synchronously handle each incoming message.
With the above requirements, which of the following approach is the correct one (with its reasoning)?:
Implementing modules as processes, and messaging through shared memory
Implementing modules as threads in a single process, and messaging by pushing message objects to the destination module's message queue.
Of source, there are some apparent cons & pros:
In Option-2, if one module causes segmentation fault, the process (thus the whole application) will crash. And one module can access/mutate another module's memory directly, which can lead to difficult-to-debug runtime errors.
But with Option-1, you need to take care of the states where a module you need to communicate has just crashed. If there are N modules in the software, there can be 2^N many alive/crashed states of the system that affects the algorithms running on the modules.
Again in Option-1, sender cannot assume that the receiver has received the message, because it might have crashed at that moment. (But the system can alert all the modules that a particular module has crashed; that way, sender can conclude that the receiver will not be able to handle the message, even though it has successfully received it)
I am in favor of Option-2, but I am not sure whether my arguments are solid enough or not. What are your opinions?
EDIT: Upon requests for clarification, here are more specification details:
This is an embedded application that is going to run on Linux OS.
Unfortunately, I cannot tell you about the project itself, but I can say that there are multiple components of the project, each component will be developed by its own team (of 3-4 people), and it is decided that the communication between these components/modules are through some kind of messaging framework.
C/C++ will be used as programming language.
What the 'Module Interface API' will automatically provide to the developers of a module are: (1) An message/event handler thread loop, (2) a synchronous message queue, (3) a function pointer member variable where you can set your message handler function.
Here is what I could come up with:
Multi-process(1) vs. Single-process, multi-threaded(2):
Impact of segmentation faults: In (2), if one module causes segmentation fault, the whole application crashes. In (1), modules have different memory regions and thus only the module that cause segmentation fault will crash.
Message delivery guarantee: In (2), you can assume that message delivery is guaranteed. In (1) the receiving module may crash before the receival or during handling of the message.
Sharing memory between modules: In (2), the whole memory is shared by all modules, so you can directly send message objects. In (1), you need to use 'Shared Memory' between modules.
Messaging implementation: In (2), you can send message objects between modules, in (1) you need to use either of network socket, unix socket, pipes, or message objects stored in a Shared Memory. For the sake of efficiency, storing message objects in a Shared Memory seems to be the best choice.
Pointer usage between modules: In (2), you can use pointers in your message objects. The ownership of heap objects (accessed by pointers in the messages) can be transferred to the receiving module. In (1), you need to manually manage the memory (with custom malloc/free functions) in the 'Shared Memory' region.
Module management: In (2), you are managing just one process. In (1), you need to manage a pool of processes each representing one module.
Sounds like you're implementing Communicating Sequential Processes. Excellent!
Tackling threads vs processes first, I would stick to threads; the context switch times are faster (especially on Windows where process context switches are quite slow).
Second, shared memory vs a message queue; if you're doing full synchronous message passing it'll make no difference to performance. The shared memory approach involves a shared buffer that gets copied to by the sender and copied from by the reader. That's the same amount of work as is required for a message queue. So for simplicity's sake I would stick with the message queue.
in fact you might like to consider using a pipe instead of a message queue. You have to write code to make the pipe synchronous (they're normally asynchronous, which would be Actor Model; message queues can often be set to zero length which does what you want for it to be synchronous and properly CSP), but then you could just as easily use a socket instead. Your program can then become multi-machine distributed should the need arise, but you've not had to change the architecture at all. Also named pipes between processes is an equivalent option, so on platforms where process context switch times are good (e.g. linux) the whole thread vs process question goes away. So working a bit harder to use a pipe gives you very significant scalability options.
Regarding crashing; if you go the multiprocess route and you want to be able to gracefully handle the failure of a process you're going to have to do a bit of work. Essentially you will need a thread at each end of the messaging channel simply to monitor the responsiveness of the other end (perhaps by bouncing a keep-awake message back and forth between themselves). These threads need to feed status info into their corresponding main thread to tell it when the other end has failed to send a keep-awake on schedule. The main thread can then act accordingly. When I did this I had the monitor thread automatically reconnect as and when it could (e.g. the remote process has come back to life), and tell the main thread that too. This means that bits of my system can come and go and the rest of it just copes nicely.
Finally, your actual application processes will end up as a loop, with something like select() at the top to wait for message inputs from all the different channels (and monitor threads) that it is expecting to hear from.
By the way, this sort of thing is frustratingly hard to implement in Windows. There's just no proper equivalent of select() anywhere in any Microsoft language. There is a select() for sockets, but you can't use it on pipes, etc. like you can in Unix. The Cygwin guys had real problems implementing their version of select(). I think they ended up with a polling thread per file descriptor; massively inefficient.
Good luck!
Your question lacks a description of how the "modules" are implemented and what do they do, and possibly a description of the environment in which you are planning to implement all of this.
For example:
If the modules themselves have some requirements which makes them hard to implement as threads (e.g. they use non-thread-safe 3rd party libraries, have global variables, etc.), your message delivery system will also not be implementable with threads.
If you are using an environment such as Python which does not handle thread parallelism very well (because of its global interpreter lock), and running on Linux, you will not gain any performance benefits with threads over processes.
There are more things to consider. If you are just passing data between modules, who says your system needs to use either multiple threads or multiple processes? There are other architectures which do the same thing without either of them, such as event-driven with callbacks (a message receiver can register a callback with your system, which is invoked when a message generator generates a message). This approach will be absolutely the fastest in any case where parallelism isn't important and where receiving code can be invoked in the execution context of the caller.
tl;dr: you have only scratched the surface with your question :)
What the difference between message queues and thread pools?
Message Queue is used for (asynchronous) inter-process communication while a Thread Pool is used to run multiple tasks on a set of threads. I can't think of a reasonable way to compare them... they're fundamentally different from each-other in so many ways.
The real question would be whether there's any similarity between the two. A message queue is a data structure for holding messages from the time they're sent until the time the receiver retrieves and acts on them.
A thread pool is a pool of threads that do some sort of processing. A thread pool will normally have some sort of thread-safe queue attached to allow you to queue up jobs to be done. This would more often be called something like a "task queue" than a message queue, though it will normally contain some sort of messages that describe the tasks that need to be done.
message queue usually used in distributed system, thread pool often used in individual machine. btw thread pool use blocking queue internally. if you use message queue, you will cost more time to maintain it. Don't over-designed.
Of course, message queue hava more complex features, and good at decoupling.
(ps: u can look at the question：Why are message queues used insted of mulithreading? )
I cannot find any information about the thread-safety of the waveOut API.
After i creating new waveOut handle, i have those threads:
Thread 1: Buffers handling. Uses those API functions:
waveOutPrepareHeader
waveOutWrite
waveOutUnprepareHeader
Thread 2: Gui, Controller thread. Uses those API functions:
waveOutPause
waveOutRestart
waveOutReset
waveOutBreakLoop
Those two threads are running while using concurrently the same waveOut handle.
In my tests, i didn't saw any problem with the functionality, but it doesn't mean that it safe.
Is this architecture thread-safe?
Is there any documentation about the thread safety of the waveOut API?
Any other suggestions about the waveOut API thread-safety?
thanks.
In general the waveOut API should be thread-safe. Because usually a waveOutOpen() creates its own thread, and all waveOut* functions send messages to that thread. But I can not give you a proof...
However, you can change your application to make it safe in any case:
start your thread for buffer management, remember dwBufferThreadId
from GUI thread call waveOutOpen with dwCallback set to dwBufferThreadId and fdwOpen to CALLBACK_THREAD
your buffer management thread: "waveOutWrite" some buffers in advance, the loop on GetMessage()
waveOutOpen will send a WOM_DONE whenever a buffer is finished and a new buffer is required, this is the moment to waveOutWrite a new buffer from within that thread
make your calls to waveOutPause, waveOutRestart and so on from GUI thread (nothing in MSDN speaks against it, and all examples do this, even if the buffers will be filled from another thread)
example 1
If you want to be 100% sure, you could just grab a windows message (WM_USER+0), and call PostThreadMessage( WM_USER+0, dwBufferThreadId, MY_CTL_PAUSE,0 ) and then upon receiving that message in your buffering thread, you call waveOutPause() there. Windows message queues save you some work on writing your own message queues ;-)
I didn't see any documentation either, but I can't imagine that a call to waveOutWrite would be considered safe to be run concurrently with a call to WaveOutRestart on the same handle.
If you're using VS2010 Beta2 I would look at the various walkthroughs for the Agents Library and attempt to turn this into a producer consumer problem where you are passing messages like write,pause,restart, etc.
If you aren't using Visual Studio 2010 (or can't) I would encourage you to find a way to break this into a producer consumer problem using threads and some sort of internally synchronized queue that stores the commands to process. If the messages aren't that frequent and given that you only have 2 threads working on this queue, you may be able to get away with puting a plain old Win32 critical section around a std::queue...
hope this helps.
Sadly, it's not safe even in a single threaded environment. Look at this question for a discussion:
Why would waveOutWrite() cause an exception in the debug heap?
Attempts to report this to Microsoft resulted in them closing the bug. They're not going to fix it.
It may be thread safe, but if you (or I) can't find any official documentation stating it is thread safe then assume it isn't and add your own thread synchronization. A light weight EnterCriticalSection / LeaveCriticalSection implementation is probably no more than a dozen lines of code.
No amount of testing can ever assure you that the API is thread safe: problems may only occur on some architectures with some CPU or bus speeds or with some sound cards. Neither you (nor Microsoft) has the ability to test all possible configurations.
You also shouldn't make any assumptions about what Microsoft or Intel or a sound card manufacturer or driver writer will do in some future implementation.
Is there any way to share a message queue among several threads, or otherwise to read a message queue of a different thread, without using hooks?
GetMessage and PeekMessage only read messages for the current thread, you can't use them to read messages sent to the input queue owned by another thread.
Try joining the thread input queues using AttachThreadInput, that might work.
Messages in a message queue can be differentiated on the basis of the window they're for, but I don't think messages can be differentiated on the basis of an inteded thread - the fields just aren't there in the MSG structure - so I don't think you can share a queue over multiple threads.
That leaves you with a non-hook monitoring solution.
I'm pretty sure you could peek another threads queue, but the problem is you're basically polling; so you'll miss messages.
Do you have any influence over the threads you wish to read? if so, you can get them to rebroadcast their messages to you.
Apart from that, I can't see a way to do this.
I want to send a message to a thread and handle it in the thread. How can I do this in Delphi? I guess PostMessage is the way to go, but the examples I've seen so far are describing the other way, i.e. from the thread to main thread.
I won't even try and explain or write any code. Just look at this tutorial. It's a little old, but very good imho.
Multithreading - The Delphi Way
You can either have a message loop (possibly with a hidden notification window) in your thread and send a Windows message to it, or you can use a more native (less-GUI) way of doing it, such as a queue protected by a critical section combined with a manual-reset event that the thread waits on and the sending thread signals.
A more general solution is a producer-consumer queue, which in the classic implementation uses a couple of semaphores to keep track of consumers and producers and a third semaphore for mutually exclusive access to the queue; however, more optimal producer-consumer queues are available on the net.
Why would you need to do it? It is only for one reason that I ever had to create a message loop in a secondary thread, and that is because the thread used COM objects. The calls to OleInitialize() and OleUnitialize() are a sign that you need a standard GetMessage() loop. In that case it's also necessary to just post messages to that thread, using PostThreadMessage(), because normal blocking synchronization calls would interfere with the message loop. Otherwise, just don't do it.
If you are at Delphi 2007 or 2009, be sure to look into OmniThreadLibrary by Primož Gabrijelčič, it should make your job much easier.