Date: Mon, 19 Mar 2007 17:05:59 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Joerg Sonnenberger <joerg@britannica.bec.de> Cc: freebsd-hackers@freebsd.org Subject: Re: Pthread spin locks Message-ID: <Pine.GSO.4.64.0703191658100.21146@sea.ntplx.net> In-Reply-To: <20070319204048.GB24514@britannica.bec.de> References: <20070319175908.35326.qmail@web32911.mail.mud.yahoo.com> <Pine.GSO.4.64.0703191403440.21146@sea.ntplx.net> <20070319204048.GB24514@britannica.bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 19 Mar 2007, Joerg Sonnenberger wrote: > On Mon, Mar 19, 2007 at 02:04:58PM -0400, Daniel Eischen wrote: >> No, especially if the threads hold other locks. >> I have no idea why POSIX added spinlocks. I don't >> see why anyone would want to use them. > > Given that it is part of the realtime extensions, it makes sense. On > those systems you generally also have policies for scheduler control > like CPU affinity, which can make the starvation impossible. PTHREAD_PRIO_PROTECT and PTHREAD_PRIO_INHERIT POSIX doesn't seem to have specified APIs for scheduler affinity and has said that the behavior of threads in scheduling domains > 1 is implementation defined. So it is somewhat surprising to me that spinlocks were added. It also assumes that the implementation of non-spin mutexes is inefficient which is not necessarily the case. It is certainly possible for the implementation to use adaptive mutexes which spin for a bit before sleeping. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0703191658100.21146>