Message Queues
6-24
Figure 6-8. Events on Sending Message to Remote Processor
For transports that are zero-copy based (for example, using shared memory),
the transport simply signals the other side that a message is present. There
are no intermediate allocations or frees in this case. The reader is still
responsible for freeing or re-using the received message.
In either type of transport, the allocator configuration must be the same on
different processors. Take the following two examples:
❏ Zero-copy based remote transport. If allocator 0 is a shared memory
allocator on processor A, then allocator 0 on processor B must act on that
same shared memory.
❏ Copy based remote transport. If allocator 1 allocates messages of size
64 bytes, then allocator 1 on processor B must also allocate messages
of 64 bytes (if messages are flowing in both directions). The underlying
allocation mechanisms may be different, but the sizes of the messages
must be the same.
Routing is the ability to send a message from one processor to another
processor via an intermediate processor. Routing is needed when there is no
physical link between two processors. Routing is not directly supported by the
MSGQ module. Routing can be built on top of the MSGQ module, but must
be managed at the application level. For example, you might create a thread
that acts as a router.
MSGQ
1. MSGQ_put()
2. put()
3. Queue msg
internally
5. Free msg via
MSGQ_free()
return to caller
Local
Processor
Remote
Processor
local
application
remote
transport
allocator allocator MSGQ
remote
transport
Physical
Link
local
application
physical link
7. Queue msg
4. Copy msg across
5. MSGQ_alloc()
buf to put msg into
6. MSGQ_put() on local
transport
on repository
To Next Page
Loading...
Need help?
General
