From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7121 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: semaphore redesign Date: Mon, 2 Mar 2015 17:45:39 -0500 Message-ID: <20150302224539.GC23507@brightrain.aerifal.cx> References: <20150301173048.GD16260@port70.net> <20150301175009.GE16260@port70.net> 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 1425336363 24816 80.91.229.3 (2 Mar 2015 22:46:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Mar 2015 22:46:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7134-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 02 23:46:03 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YSZ6B-0002Xa-8Y for gllmg-musl@m.gmane.org; Mon, 02 Mar 2015 23:46:03 +0100 Original-Received: (qmail 18287 invoked by uid 550); 2 Mar 2015 22:46:01 -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 18234 invoked from network); 2 Mar 2015 22:45:51 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7121 Archived-At: On Tue, Mar 03, 2015 at 01:40:37AM +0300, Alexander Monakov wrote: > On Sun, 1 Mar 2015, Szabolcs Nagy wrote: > > sorry > > > > the code is ok (applications cannot rely on the barrier in case of > > failure), it can lead to surprising results if the application > > uses relaxed atomics, but it's not a conformance issue > > There was some follow up on IRC with the conclusion, as I understood, that > even though the rest of memory may be unsynchronized after returning an error, > the memory holding the semaphore itself needs to be synchronized (otherwise > the decision to return an error might have been based on stale memory). Right. The exemption from formally synchronizing memory in the case of errors does not give license to falsely report errors due to failure of the implementation to detect that it's in a non-error state. That would just be an implementation bug. > Does sem_getvalue need to synchronize memory as well? I think it should, but > current implementation does not. sem_getvalue is required return a value that was valid at some time during the call. There's no formal requirement to "synchronize memory" in the POSIX sense AFAIK, but if a barrier is required to meet the requirement for the value, it should use one. Rich