Date: Fri, 20 Feb 2004 22:54:29 +0100 From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) To: Daniel Eischen <eischen@vigrid.com> Cc: threads@freebsd.org Subject: Re: cross-thread locking Message-ID: <xzp65e1s9gq.fsf@dwp.des.no> In-Reply-To: <Pine.GSO.4.10.10402201525290.3738-100000@pcnet5.pcnet.com> (Daniel Eischen's message of "Fri, 20 Feb 2004 15:28:10 -0500 (EST)") References: <Pine.GSO.4.10.10402201525290.3738-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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#tag_= 03_02_09 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?) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzp65e1s9gq.fsf>