You could do worse than Mach ports

Matthew Dillon dillon at apollo.backplane.com
Fri Jul 18 11:50:39 PDT 2003


:>     So integrating those functions into
:>     the core messaging system just adds more conditionals the critical path,
:>     making the core messaging system less efficient without any peformance
:>     improvements to show for it.
:
:Actually, there's a rather nice model, where you register the
:event you are interested in, unlock, and then block waiting for
:the interesting event.  By decoupling this, you protect yourself
:completely against races.  In general, you can get by with having
:an interest in only a single event, meaning that you don't have
:to implement chaining, stacking, etc., for the notification or
:registration of interest: you just spam the old values with the
:new to indicate interest, and the block is a clock on the address
:of an object (not unlike tsleep).
:...
:-- Terry

    I far prefer the model where you keep the lock but get a message-back
    if someone else wants it or would conflict with it, because it allows
    you to 'delay' all the cruft that would otherwise be involved in
    releasing the lock.  It allows the caching mechanism to extend into
    user space mappings almost trivially.

    If a user mmap()'s a portion of a file which you wish to remain cache
    coherent across the cluster, you obtain and retain an appropriate
    range lock (shared if there are no dirty pages, exclusive if there are
    dirty pages or currently-writable pages) on the mapped area via the
    VM object.  If another machine in the cluster tries to map an overlap
    R+W you would get a message-back invalidation request.  You would then
    be able to act on that request to modify the page mapping (e.g. invalidate
    the PTEs and clear your lock, or make them read-only and downgrade your
    lock, etc). 

    You can't get much more efficient then that in a clustered environment!

    Deadlocks are also easier to deal with with this positive-control
    methodology.  A central (or other) deadlock detection mechanism would
    have incredible flexibility and choice in regards to who and what it
    asks existing lock holders to do to resolve the deadlock.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list