Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Pulses
you received a message and set when you replied to a message. Just before you replied
to the message, you’d check the flag. If the flag indicates that the message has already
been replied to, you’d skip the reply. The mutex would be locked and unlocked around
the checking and setting of the flag.
Unfortunately, this won’t work because we’re not always dealing with two parallel
flows of execution — the client won’t always get hit with a signal during processing
(causing an unblock pulse). Here’s the scenario where it breaks:
• The client sends a message to the server; the client is now blocked, the server is
now running.
• Since the server received a request from the client, the flag is reset to 0, indicating
that we still need to reply to the client.
• The server replies normally to the client (because the flag was set to 0) and sets the
flag to 1 indicating that, if an unblock-pulse arrives, it should be ignored.
• (Problems begin here.) The client sends a second message to the server, and almost
immediately after sending it gets hit with a signal; the kernel sends an
unblock-pulse to the server.
• The server thread that receives the message was about to acquire the mutex in order
to check the flag, but didn’t quite get there (it got preempted).
• Another server thread now gets the pulse and, because the flag is still set to a 1
from the last time, ignores the pulse.
• Now the server’s first thread gets the mutex and clears the flag.
• At this point, the unblock event has been lost.
If you refine the flag to indicate more states (such as pulse received, pulse replied to,
message received, message replied to), you’ll still run into a synchronization race
condition because there’s no way for you to create an atomic binding between the flag
and the receive and reply function calls. (Fundamentally, that’s where the problem lies
— the small timing windows after a MsgReceive() and before the flag is adjusted, and
after the flag is adjusted just before the MsgReply().) The only way to get around this
is to have the kernel keep track of the flag for you.
Using the _NTO_MI_UNBLOCK_REQ
Luckily, the kernel keeps track of the flag for you as a single bit in the message info
structure (the struct _msg_info that you pass as the last parameter to
MsgReceive(), or that you can fetch later, given the receive ID, by calling MsgInfo()).
This flag is called _NTO_MI_UNBLOCK_REQ and is set if the client wishes to
unblock (for example, after receiving a signal).
This means that in a multithreaded server, you’d typically have a “worker” thread
that’s performing the client’s work, and another thread that’s going to receive the
unblock message (or some other message; we’ll just focus on the unblock message for
April 30, 2009 Chapter 2 • Message Passing 123