[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170705214150.GB1627@brightrain.aerifal.cx>
Date: Wed, 5 Jul 2017 17:41:50 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: move to a proper __lock_t type
On Wed, Jul 05, 2017 at 10:53:06PM +0200, Jens Gustedt wrote:
> I am not much a fan of the a_..._l primitives either. I came up with
> it here, because we would need it in the transformation of the memcpy
> logic that we discussed, where the atomic type to be copied is
> implemented as "volatile unsigned long[something]".
It's not needed as long as volatile remains there. You can just use a
for loop doing direct reads of the volatile long array.
> > > (2) Replace all occurences of "volatile int[2]" by "__lock_t" that
> > > encapsulates just that in a struct.
> > >
> > > (3) Replace the __lock/__unlock pair by the new algorithm
> > >
> > > (4) Reduce "__lock_t" to a struct that simply has a "volatile int"
> > > as sole member.
> >
> > Can we avoid cosmetics/refactoring like this until the new algorithm
> > goes in?
>
> what is "this" here, (2) and (4) ?
Yes, that sounds right.
> > I just have a backlog of stuff to review and commit, and the
> > new algorithm is something I really want to get included for release
> > since it fixes a visible bug (even if hard to hit the race), and
> > having to go back and start again with refactored versions sets that
> > back.
>
> Ok, no problem that can wait. Do you need more input for me on the new
> algorithm?
I think it's okay. Going to read again. It strikes me as a bit
over-optimized for locks that are minimal contention and not
bottlenecks, but if it ends up also being used for malloc it makes
sense having it optimized.
> > > In all of that, would we need the "__" in the name of the
> > > structure? I think this name will never be exported.
> >
> > I don't think so, but it might be nice to signify to someone reading
> > the code that it's not a public type. It might also be mildly nicer in
> > the debugger if the application also happens to define a type named
> > lock_t.
>
> right
>
> > I'm open to other names too.
>
> I personally don't like the "..._t" naming convention too much, but
> "__lock" is already taken for the function. "_Lock", "_Lck" ?
I don't like stepping into _[A-Z] much since it seems to be the naming
convention that the committee has chosen for expending the language
itself. I'll think about whether there are other ideas I like.
One minor concern: if we do make it a struct type, there are possibly
formal aliasing issues with having it embedded in any of the public
pthread types (cond vars, maybe barriers?) without a public
definition. Perhaps it should be an int array typedef (length 1) or
just a typedef'd int?
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.
