[cap-talk] A Taxonomy of Current Object-Cap Systems

Marcus Brinkmann marcus.brinkmann at ruhr-uni-bochum.de
Fri Mar 6 10:37:25 EST 2009

Toby Murray wrote:
> On Thu, 2009-03-05 at 21:53 +0100, Marcus Brinkmann wrote:
>> Toby Murray wrote:
>>> If a systems is missing above that you think should be included, please
>>> let me know.
>> Mach
> I wasn't aware that Mach was object-capability (I'm not trying to imply
> that I thought it was otherwise however). Is there documentation or a
> paper I can refer to that talks about its current incarnation? 

The GNU Mach comes with a texinfo document that documents its interface, but
you can just as well refer to the original documentation:


You are in particular looking for:


If you are being picky, there is some ambient authority in Mach: There is a
special system call that allows every thread to get its own thread port (and I
think the task port, too).  That's a special system call, which can be
optimized.  I'd rather see this as an extension of the architectures
instruction set.

>> Well, I can tell you that Mach supports synchronous and asynchronous message
>> send and receive between threads and provides a full EQ? operation for all
>> kernel-implemented objects.
> Great. Could you elaborate on how the asynchronous sends work? Are they
> buffered or best-effort? Mach is unique in providing asynchronous
> receives. How do they work? (I can't even imagine -- I really need to do
> some more reading.)

A bit of hand-waving is certainly involved.  A Mach port is a message queue
with room for let's say 5 messages.  Threads with send names (== capabilities)
for that port can deposit in the buffer and threads with receive names can
read them out.  Of course, the whole story is much more complex than that, as
Mach has been subject to some featurism.

If a queue is full, the sending thread blocks until there is room in the
message buffer).

The term asynchronous is really difficult to handle, as it relies on carefully
crafted illusion.  Certainly some objects need to synchronize for a message
transfer to happen, but these objects can exist independent of what we usually
call threads.  I'd say any perception of asynchrony relies on such
intermediate objects, at least I can't imagine it to be otherwise.

Mach is certainly not unique with asynchronous receive (by which I understand
that a thread can receive a message without blocking).  At least one
incarnation of the coyotos specification had that feature, too, and it would
have been easy to add to L4 X.2, too (at least for a single message).  The
reason this works is that the thread creates a message buffer object and that
messages buffer can receive a complete message (in L4 X.2 the message buffer
would be in the UTCB).  Then when the receive operation is complete, the
thread can be notified by a scheduler activation (think signals).

Asynchronous send (by which I understand that a thread can send a message
without the receiver being blocking for it, and be notified when the send
completes) is much rarer to find.  I designed a microkernel (not published)
that has full asynchronous send and receive for threads, but of course it just
works by punting all the actual message transfer to message buffer objects,
which work fully synchronous, coupled with a notification system for threads
(activations) to become aware of message buffer state changes.  This can get
pretty complicated quickly.  The point again is that the primitive operations
are synchronous, but the illusion of asynchronous is built on top of that by
buffering.  How to splice this is a matter of what operations need to be

Here is a small glossary for your Mach studies:

 message queue object in the kernel (think pipe)
port space
 c-list of a task  (think file descriptor table)
port right
 c-list entry (think file descriptor)
port name
 index into the c-list specifying a c-list entry (think fd number)


More information about the cap-talk mailing list