Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 28 Jul 2015 13:33:25 -0400
From: Rich Felker <>
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.


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.