cross-thread locking

Daniel Eischen eischen at vigrid.com
Fri Feb 20 14:08:36 PST 2004


On Fri, 20 Feb 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote:

> Daniel Eischen <eischen at vigrid.com> writes:
> > Found it.  It's in the Rationale -> System Interfaces -> General Info.
> > Here's a link that might get you there:
> >
> >   http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#ta=
g_03_02_09
>=20
> OK.  It seems to me then that our spin locks are only superficially
> conformant.  They are far heavier than the rationale suggests: they
> depend on malloc(), and they call pthread_self() which requires a full
> libpthread initialization.  That makes them unsuitable in many cases.
> For instance, a malloc() implementation can't use our spin locks to
> protect its management structures.  This happens to be a very real
> issue for me in my day job; I ended up writing my own spin lock
> implementation based solely on <machine/atomic.h> (anyone know of a
> good way to thoroughly test it, BTW?)

Put it in a shared memory region and have another process
poke at it?

Our synchronization primitives (mutexes, CVs, etc) need to change
from a <type> * to <type>, but that is an ABI change, causes a
libc version bump, etc.  The plan for 6.0 is to change this, but
since we have multiple thread libraries it also requires some
coordination.  We really need to make this change to support the
pshared attribute (sharing the locks across processes in shared
memory regions).

--=20
Dan Eischen



More information about the freebsd-threads mailing list