From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4601 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: What does this code do? Date: Sun, 23 Feb 2014 00:31:53 -0500 Message-ID: <20140223053153.GD184@brightrain.aerifal.cx> References: <20140222143536.GA5438@diogenes.samsung.router> <20140222145907.GC184@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1393133519 4590 80.91.229.3 (23 Feb 2014 05:31:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Feb 2014 05:31:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4605-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 23 06:32:08 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WHRfb-0002kJ-P2 for gllmg-musl@plane.gmane.org; Sun, 23 Feb 2014 06:32:07 +0100 Original-Received: (qmail 29834 invoked by uid 550); 23 Feb 2014 05:32:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29820 invoked from network); 23 Feb 2014 05:32:06 -0000 Content-Disposition: inline In-Reply-To: <20140222145907.GC184@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4601 Archived-At: 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