[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150728173325.GW16376@brightrain.aerifal.cx>
Date: Tue, 28 Jul 2015 13:33:25 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: What's left for 1.1.11 release?
On Tue, Jul 28, 2015 at 06:42:59PM +0200, Jens Gustedt wrote:
> Am Dienstag, den 28.07.2015, 12:07 -0400 schrieb Rich Felker:
> > On Tue, Jul 28, 2015 at 05:15:29PM +0200, Jens Gustedt wrote:
> > > Another possibility would be to squeeze the lock bit and the wait
> > > counter into a single int, and operate on the bit with some
> > > fetch_and and fetch_or operations. But that would probably be much
> > > more of a code change.
> >
> > Yes, this is the "new normal-type mutex" thread which I think you
> > already saw and commented on. I suspect it's the preferred approach in
> > the long term, but I don't like using redesigns as bug fixes
>
> agreed
>
> > unless there's something fundamentally wrong with the old design that makes
> > it impossible to fix. In this case there is no such issue. The lock
> > design is perfectly valid; x86 a_store is just buggy.
>
> Assuming just release consistency from a store operation is a
> reasonable thing to do and to have such a relaxed operation in the set
> makes sense. So somehow the error is more in the assumptions about the
> operation than in the operation itself.
Well all musl's a_* operations are intended to be seq_cst order. So
versus that intent, it really is a bug in a_store. Note that other
archs' versions of a_store perform barriers both before and after the
store to achieve seq_cst.
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.
