From owner-freebsd-threads@FreeBSD.ORG Fri Feb 20 14:08:35 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFAFE16A520 for ; Fri, 20 Feb 2004 14:08:35 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC02743D2D for ; Fri, 20 Feb 2004 14:08:35 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i1KM8XSQ002761; Fri, 20 Feb 2004 17:08:33 -0500 (EST) Date: Fri, 20 Feb 2004 17:08:33 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: threads@freebsd.org Subject: Re: cross-thread locking X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2004 22:08:36 -0000 On Fri, 20 Feb 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Daniel Eischen 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 (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 * to , 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