Date: Fri, 20 Feb 2004 17:08:33 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= <des@des.no> Cc: threads@freebsd.org Subject: Re: cross-thread locking Message-ID: <Pine.GSO.4.10.10402201658140.29668-100000@pcnet5.pcnet.com> In-Reply-To: <xzp65e1s9gq.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Feb 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Daniel Eischen <eischen@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10402201658140.29668-100000>