From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31977 invoked by alias); 23 Sep 2014 18:28:43 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 31942 invoked by uid 48); 23 Sep 2014 18:28:40 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug libc/17428] lll_trylock barrier semantics when lock was not acquired differ between architectures Date: Tue, 23 Sep 2014 18:28:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-09/txt/msg00248.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17428 --- Comment #1 from Rich Felker --- Could you explain the basis of your claim that C11 mtx_trylock allows spurious failures? I suspect this is a misstatement of something rather different: roughly, that there are situations where operations are non-ordered to an extent that both a view that the mutex is already locked, and a view that it's not already locked, are both consistent with everything else observable. But in cases where the mutex is, from the calling thread's perspective, provably in either the locked or unlocked state, I think mtx_trylock is required to produce an accurate result. I don't see any language that would exempt it from this requirement that's specified in its normative Description/Returns text (7.26.4.5 p2-3). As for "improving" POSIX's semantics, that's another matter, and it really depends on the outcome of the alignment process and further action by the Austin Group and sponsors. I'm still not clear on whether weakening trylock would be an improvement, and my view largely depends on the degree to which such a weakening could be inconsistent/counter-intuitive and lead to bugs, especially in applications which were correct with respect to a previous issue of the standard. But I think it's outside the scope of this glibc tracker issue. -- You are receiving this mail because: You are on the CC list for the bug.