cvs commit: src/share/man/man9 locking.9 rmlock.9 src/sys/conf files src/sys/kern kern_rmlock.c subr_lock.c subr_pcpu.c subr_smp.c src/sys/sys _rmlock.h lock.h pcpu.h rmlock.h smp.h

[Attilio Rao]

2007/11/26, Daniel Eischen <eischen at vigrid.com>:
> On Sun, 25 Nov 2007, Julian Elischer wrote:
>
> > Daniel Eischen wrote:
> >> On Sat, 24 Nov 2007, Darren Reed wrote:
> >>
> >>> Stephan Uphoff wrote:
> >>>> ups         2007-11-08 14:47:55 UTC
> >>>>
> >>>>   FreeBSD src repository
> >>>>
> >>>>   Modified files:
> >>>>     share/man/man9       locking.9     sys/conf             files
> >>>> sys/kern             subr_lock.c subr_pcpu.c subr_smp.c     sys/sys
> >>>> lock.h pcpu.h smp.h   Added files:
> >>>>     share/man/man9       rmlock.9     sys/kern             kern_rmlock.c
> >>>> sys/sys              _rmlock.h rmlock.h   Log:
> >>>>   Initial checkin for rmlock (read mostly lock) a multi reader single
> >>>> writer
> >>>>   lock optimized for almost exclusive reader access. (see also rmlock.9)
> >>>>
> >>>
> >>> Is there a white paper or other documentation around somewhere that
> >>> discusses the benefits/tradeoffs with using rmlock vs rwlock?
> >>
> >> Why aren't we using the rwlock interfaces, but just allowing a different
> >> behavior when the lock is created (rwlock_init2() or something)?  It
> >> would seem simpler to keep the same interface and allow easy toggling
> >> between rwlocks and rmlocks.  The same way we can initialize kernel
> >> mutexes differently (MTX_DEF, MTX_SPIN) could be applied here.
> >>
> >
> > I think that If anything, we should be going in the other direction..
> > firstly, mutexes are just rw_locks with no readers. So we might
> > as well make them the same thing..
>
> Robert already answered my question sufficiently...
>
> I am looking at the way Solaris does its kernel synchronizations.
> They have mutexes, CVs, and rwlocks as far as I can see.  It is very
> convenient to have mutexes and CVs just as their userland counterparts.
> Mutexes are mutual exclusion and by definition not rwlock-capable.
> You don't want to mix the mutex API with the rwlock or rmlock APIs,
> and also, the CV APIs (cv_waitXXX, cv_timedwaitXXX) only take mutex
> types as arguments.  If the implementations can share code, ok, but
> don't share the mutex/CV APIs with the r{mw}lock APIs :-)

If you are referring to our implementation, CVs get rwlock and sxlock as well.
They could theorically get rmlock as well, but currently locking /
unlocking operations aren't still implemented in the generic layer.

> > Spin and blocking mutexes should in my opinion be defined as different
> > structures, at least in name so that the compiler hits you with a clue-bat
> > when you try use a spin-lock with non-spinlock ops etc.
>
> That seems nice, but doesn't go along well with trying to keep a
> similar API as Solaris.  It is convenient to share the APIs so
> that it is easy to change the mtx_init() from a default to a spin
> type without changing the rest of the code.  We really shouldn't
> have a need for spin mutexes if the default mutexes are adaptive,
> and if mutexes taken by interrupt handlers are initialized in a
> manner similar to Solaris.  There really shouldn't be a separate
> API for spin mutexes.  Once a mutex is initialized as MTX_DEF
> or MTX_SPIN, that should be sufficient.

Well, honestly spin-mutex should never be used on consumer code.
They should be used only in very special contexts (like fast handler /
interrupt filter) or however code running in kernel context.
Generally, we discourage their usage (just consider CV, callout and
sleep_* don't support them) at higher lever than necessary.
I see a usual mistake cames from people porting Linux drivers and
using it, even when not necessary.

Maybe we should have a clearer documentation on how using netbus
methods and what locking should be in their regards?

> > not sure why sx-locks exist at all, as they seem to be a variant of sleep.
> > I think it's just a convenience function set to allow one to implement
> > a sleep-derived synchronisation.
>
> Hmm, sx locks seem similar to rmlocks, at least according to the
> description:
>
>    Shared/exclusive locks are used to protect data that are read far
>    more often than they are written.
>
> Do we need both?

rmlock are like rwlock from a low level perspective, but they are very
different from sxlock.

rmlock and rwlock use turnstiles as back-end primitive for blocking
threads and handling wakeup event.
sxlock use sleepqueues as back-end primitive and they are, as rightly
expressed here, a variant of sleeping which handle sleep / wakeup
efficiently.

Some rules about locking should be:
- Prefer always primitives using turnstiles as back-end (so mutex,
rwlock and rmlock)
- Try to not recurse, except than in rare cases
- Try to maintain limitated usage of sxlock and spinlock

These rules in practice are applied not in a strong way.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein