This is the mail archive of the 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: sparc nptl mystery resolved

From: Roland McGrath <>
Date: Fri, 27 Jun 2014 15:15:51 -0700 (PDT)

> Incidentally, the "sparc-specific" code is so similar to the stock code
> that I'd suggest you do some refactoring so it can share most of the source
> instead of duplicating it.  But I haven't looked at all the details, so
> maybe it's less similar than I think.

The difference is that for sparc 32-bit we put an explicit byte
spinlock into the semaphore structures since pre-v9 32-bit we lack
atomic operations other than "ldstub" (load and store byte atomic).

That's also why we have the funny 24-bit atomic integers, so we can
use the upper 8-bits for the byte spinlock.

This strategy, of cource, has a whole host of issues.  Worst of which
is that we can (and do) deadlock with signals.

I wish Jakub Jelink and I had to foresight decades ago to do what
other platforms do to handle this situation, which is to have kernel
calls which provide atomic operations. :-/

> On the roland/nptl branch there are a few nptl/ test failures in the
> sparc-linux build that don't show up in the sparcv9-linux build.  I presume
> those were preexisting problems and nobody was testing it or caring.

Those, I am pretty sure, were existing problems.


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