Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 5 Jul 2017 17:41:50 -0400
From: Rich Felker <>
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?


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.