Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Jun 1999 18:53:30 -0400
From:      Bakul Shah <bakul@torrentnet.com>
To:        Julian Elischer <julian@whistle.com>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, freebsd-smp@FreeBSD.ORG
Subject:   Re: high-efficiency SMP locks - submission for review 
Message-ID:  <199906272253.SAA04385@chai.torrentnet.com>
In-Reply-To: Your message of "Sun, 27 Jun 1999 14:34:40 PDT." <Pine.BSF.3.95.990627142319.8298I-100000@current1.whistle.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
>  2/ Before we rush off and implement a new set of locking primatives,
>     it might be a good idea to look at the locking primatives of a few
>     other OS's.. For example Linux and MACH, and if we can get hold of
>     them, Solaris and maybe the exokernel. (and sprite)
> 
>  3/ This is not to say that what you have done is bad, but that there
>     is something to be said for not being gratuitously different. It
>     might also be the case that the other BSDs might be doing something
>     with locks.
> 
>  4/ If you want to implement these locks it really is up to you to do
>     a quick scan of what the "state of the art" is in this field.
> 
>     I think I can dig up MACH2.5 (OSF1/digital unix/true64) locks
> 
>     maybe we should make a call for everyone on the freebsd lists to
>     see what they can find in their own back yards. Of course the use
>     of await() gives a good head start for us..

Has anyone taken a serious look at wait-free or lock-free or
NonBlocking Synchronization (NBS) primitives?  There are
papers on this going back 27 years or so.  Recent papers by
Michael Greenwald & David Cheriton, Michael Scott etc. may be
more accessible.

The basic idea is to rely on a processor/hardware provided
atomic compare-and-swap or double compare-and-swap
instruction to update data structures atomically.  If the
update does not succeed you retry or do something else (but
the data structure remains consistent either way).

You can think of a spinlock as a trivial example of this but
the idea is to *not* use any sort of lock when there is a
high likelyhood of success with NBS.  It is not a panacea but
it does seem to have other benefits like no priority
inversion, higher degree of usable concurrency etc.  You would
need to built primitives for mutual exclusion on top of that
for tasks that depend on other entities (e.g. disk access).

IMHO any use of NBS would likely result in a redesign rather
than an addition of yet another way to synchronize so it is
not for the faint of heart.

Henry Massalin's thesis on the Synthesis kernel would also be
useful reading.  It is full of so many interesting ideas I am
amazed no one has stolen most of them as yet!

-- bakul


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906272253.SAA04385>