Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Feb 2004 14:45:43 -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.10402201439320.19728-100000@pcnet5.pcnet.com>
In-Reply-To: <xzpn07dspqv.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:
> > 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10402201439320.19728-100000>