[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150302224539.GC23507@brightrain.aerifal.cx>
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.
