[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140223053153.GD184@brightrain.aerifal.cx>
Date: Sun, 23 Feb 2014 00:31:53 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: What does this code do?
On Sat, Feb 22, 2014 at 09:59:07AM -0500, Rich Felker wrote:
> Unfortunately, since we want to support both old and new kernels
> (where old kernels lack it), we need a way to fallback to not using
> private futex mode if it's not supported. Also, the synchronization
> object needs to accurately reflect whether the application requested
> it be process-shared, so that we can avoid using private futex mode
> when it's not valid to do so. Making the fallback reasonably efficient
> is not easy; we want to cache the result, but storing it globally
> would incur synchronization cost and GOT access cost on each futex
> operation (potentially expensive in bloat as well as time) while
> storing it in TLS would incur thread-pointer access time (very slow on
> some archs) for each operation and have the risk of threads
> mismatching each other's choices due to spurious failures by the
> kernel (not sure if these exist or not) that could lead to deadlocks.
> So adding support, while it's been an agenda item for a long time,
> requires nontrivial work/research on how to do it right (note: I'm not
> convinced glibc does it right).
I may have a solution for this that avoids any costly synchronization
or TLS access: check the availability of private futexes during the
first call to pthread_create. No synchronization is required at this
point (since no other threads exist yet) and no operation can care
whether private futexes are supported prior to pthread_create (since
there are no threads that can contend for non-process-shared
synchronization objects). We can store the private futex flag in the
"libc" structure too so it's accessible via PC-relative/GOT-relative
addressing rather than needing a GOT lookup.
Unless anyone sees serious flaws in this approach (note: the extra
futex syscall to test for private futex availability during the first
call to pthread_create has nonzero cost, but it's dwarfed by the cost
of clone and other operations, so IMO that's not an issue) I'll plan
to go with this approach to adding private futex support. I don't want
to risk breakage now though so I'll do it after 1.0, possibly as its
own change in 1.0.1 or so, and otherwise as part of the changes to
make the thread pointer always-valid in the 1.1.x series.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
