Message Queues
Input/Output Methods 6-23
6.5.5 Multi-Processor Issues
One of the key features of the MSGQ module is transparency in a multi-
processor environment. Moving a reader from one processor to another
causes no change in the writer code. Similarly, moving a writer to another
processor causes no change in the reader.
On each processor, there is one transport for each of the other processors.
For instance, in a system that has four processors that communicate with
each other, each processor must have three transports (one to talk to each of
the other three processors) and one MSGQ_NOTRANSPORT transport. If
two processors have more than one physical link between them (for example,
shared memory and serial), it is up to the transport to manage the two links
(for example, to determine which messages go on which link)
When a message is allocated, the ID of the allocator is embedded into the
MSGQ_MsgHeader portion of the allocated message. This makes it easy to
free the message later. That is, the application does not need to remember
which allocator was used to allocate the message.
Some transports are copy-based. When such transports send a message to
a remote processor, the message is copied to the physical link (for example,
TCP/IP). In the case of a copy-based transport, the transport on the source
processor frees the message after it is copied. The transport on the
destination processor allocates a message and sends it to the destination
message queue. All the transport's allocations and frees are transparent to
the application. The reader thread is still responsible for freeing or re-using
the received message.
The following figure shows the sequence of events that occur when sending
a message to a remote processor via a copy-based transport. After these
events, the message can be received via a MSGQ_get on the remote
processor.
To Next Page
Loading...
Need help?
General
