Date: Sun, 22 Sep 1996 02:51:56 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jmb@freefall.freebsd.org (Jonathan M. Bresler) Cc: terry@lambert.org, bad@owl.WPI.EDU, freebsd-smp@FreeBSD.org Subject: Re: multithreading in the kernel and applications. Message-ID: <199609220951.CAA00353@phaeton.artisoft.com> In-Reply-To: <199609220252.TAA04067@freefall.freebsd.org> from "Jonathan M. Bresler" at Sep 21, 96 07:52:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Mutexes is meant to refer to "mutual exclusion locks which function
> > between processors".
> >
> > Semaphores is meant to refer to "mutual exclusion locks which do
> > not use memory shared between CPU's for their implementation".
> >
> > If you lock with a semaphore, you don't lock out other CPU's from
> > accessing the same object (ie: they may have stale cache data),
> > but mutexes invoke a bus abritration cycle to make sure there are
> > no stale caches on other processors.
> >
>
> isnt that an implementation issue, whatever form of mutex is
> used a data structure must be shared among the processors
> and if cached must be either flushed or invalidated (hopefully
> via a hardware protocol such as MESI)
>
> what method are you referring to that does not require
> shared data? are there any papers available about it? or
> am i misunderstanding you?
A hierarchy with intention modes.
IF you invoke a mutex without sharing which is an inferior node in
a hierarchy of nodes, where some superior node is a mutext *with*
sharing, THEN as long as the superior node has an intention mode
established, the actual locking can be local to the inferior node.
And thus local to a single processor and image of cache coherency...
no additional bus arbitration need take place.
In effect, you would establish a hierarchy of per-CPU "top level in
the context of a single CPU" mutexes which could be used without
forcing an update cycle. to the top level ("system wide") mutex.
> > Yes. A processor can "enter" an execution context. If the execution
> > contexts are arbitrated in the kernel via inter-CPU mutexes, then
> > multipl CPU's can enter execution contexts in kernel space at the
> > same time.
>
> i have not yet read the smp source in FreeBSD. what
> granulaarity of laocking are we using? what structures
> are currently protected? do both cpus have the same
> "privilege" or "priority" ( i am missing the correct term
> here) can both field interrupts for instance?
Locking occurs at system call trap, interrupt handling, and as the
result of processor/mmu exceptions.
In other words, we are using the lowest possible locking granularity
which can still be called SMP. User space is reeentrant, but the
kernel is not.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609220951.CAA00353>