This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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" <macro@codesourcery.com>
> >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
> path.

The only reason NPTL presently works without CAS is that it's
non-conforming; see the following bug report:

http://sourceware.org/bugzilla/show_bug.cgi?id=12674

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).

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]