This is the mail archive of the
mailing list for the glibc project.
Re: Support for i386 builds of glibc?
On Wed, Mar 06, 2013 at 10:27:30AM +0100, Florian Weimer wrote:
> On 03/04/2013 10:11 PM, David Miller wrote:
> >From: "Maciej W. Rozycki" <firstname.lastname@example.org>
> >Date: Mon, 4 Mar 2013 20:56:08 +0000
> >>They could be easily emulated with the aid of global spinlocks, but
> >>given the decline of the i386 it's probably not worth the effort.
> >This is a misnomer, you can't use global spinlocks as those are not
> >signal safe and will deadlock. Even the glibc testsuite will trigger
> >such deadlocks.
> i386 supports atomic increment and decrement. This should be
> sufficient for NPTL, its use of CAS stems from an optional
> optimization not really required for using futexes. So a
> hypothetical i386 version would not need a system call on the fast
The only reason NPTL presently works without CAS is that it's
non-conforming; see the following bug report:
The same issue applies to ALL of NPTL's synchronization primitives.
I'm not aware of a general solution to the self-synchronized
destruction problem that doesn't involve either CAS or unconditional
futex wake calls on every single unlock operation (even uncontended).