Date: Mon, 26 Nov 2007 11:17:06 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Daniel Eischen" <eischen@vigrid.com> Cc: src-committers@freebsd.org, current@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, Julian Elischer <julian@elischer.org>, Stephan Uphoff <ups@freebsd.org> Subject: Re: 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 Message-ID: <3bbf2fe10711260217p45362826wc03c7f4ee3d224a@mail.gmail.com> In-Reply-To: <Pine.GSO.4.64.0711260008090.11036@sea.ntplx.net> References: <200711081447.lA8EltXO052057@repoman.freebsd.org> <47492064.7080108@freebsd.org> <Pine.GSO.4.64.0711251207590.8538@sea.ntplx.net> <4749B971.3000703@elischer.org> <Pine.GSO.4.64.0711260008090.11036@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/11/26, Daniel Eischen <eischen@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10711260217p45362826wc03c7f4ee3d224a>