From owner-freebsd-threads@FreeBSD.ORG Fri Feb 20 11:45:46 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 24E1916A4CE for ; Fri, 20 Feb 2004 11:45:46 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3EDB43D1D for ; Fri, 20 Feb 2004 11:45:45 -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 i1KJjhSQ022361; Fri, 20 Feb 2004 14:45:44 -0500 (EST) Date: Fri, 20 Feb 2004 14:45:43 -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 19:45:46 -0000 On Fri, 20 Feb 2004, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote: > Daniel Eischen writes: > > POSIX differentiates between spinlocks and mutexes, and that is > > why there is a pthread_spinlock_t instead of using pthread_mutex_t > > for both lock operations. I believe the implementation is allowed > > to spin indefinitely or schedule another thread if the lock is > > busy. >=20 > In other words, the semantics for the two are identical? Yes, you use them in the same way. > BTW, I looked at the libpthread sources, and it seems to me that a > spinlock is just a wrapper around a mutex, though the comments > contradict this. I think you are looking at spinlocks, not pthread_spinlocks. Look at thr_pspinlock.c, not thr_spinlock.c. The latter is used for internal spinlock usage by libc. Libc spinlocks are unfortunately named and should just be libc_locks or something. > Going off on a tangent, is there a value one can assign to a pthread_t > to make it unambiguously invalid? Obviously, NULL or 0 will work in > FreeBSD since our pthread_t is a pointer to a struct pthread, but I'm > looking for something more portable. Not that I know of. --=20 Dan Eischen