Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. Writing a resource manager
}
sts = fchown (fd, owner, group);
close (fd);
return (sts);
where fchown() is the file-descriptor-based version of chown(). The problem here is
that we are now issuing three function calls (and three separate message passing
transactions), and incurring the overhead of open() and close() on the client side.
With combine messages, under Neutrino a single message that looks like this is
constructed directly by the client’s chown() library call:
_IO_CONNECT_COMBINE_CLOSE
_IO_CHOWN
A combine message.
The message has two parts, a connect part (similar to what the client’s open() would
have generated) and an I/O part (the equivalent of the message generated by the
fchown()). There is no equivalent of the close() because we implied that in our
particular choice of connect messages. We used the
_IO_CONNECT_COMBINE_CLOSE message, which effectively states “Open this
pathname, use the file descriptor you got for handling the rest of the message, and
when you run off the end or encounter an error, close the file descriptor.”
The resource manager that you write doesn’t have a clue that the client called chown()
or that the client did a distinct open(), followed by an fchown(), followed by a close().
It’s all hidden by the base-layer library.
Combine messages
As it turns out, this concept of combine messages isn’t useful just for saving
bandwidth (as in the chown() case, above). It’s also critical for ensuring atomic
completion of operations.
Suppose the client process has two or more threads and one file descriptor. One of the
threads in the client does an lseek() followed by a read(). Everything is as we expect it.
If another thread in the client does the same set of operations, on the same file
descriptor, we’d run into problems. Since the lseek() and read() functions don’t know
about each other, it’s possible that the first thread would do the lseek(), and then get
preempted by the second thread. The second thread gets to do its lseek(), and then its
read(), before giving up CPU. The problem is that since the two threads are sharing
the same file descriptor, the first thread’s lseek() offset is now at the wrong place —
it’s at the position given by the second thread’s read() function! This is also a problem
with file descriptors that are dup()’d across processes, let alone the network.
An obvious solution to this is to put the lseek() and read() functions within a mutex —
when the first thread obtains the mutex, we now know that it has exclusive access to
the file descriptor. The second thread has to wait until it can acquire the mutex before
it can go and mess around with the position of the file descriptor.
April 30, 2009 Chapter 5 • Resource Managers 217