Date: Mon, 2 Mar 2015 17:45:39 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: semaphore redesign 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
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.