Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Jun 2017 19:40:40 +0200
From: Jens Gustedt <>
Subject: Re: [PATCH] a new lock algorithm with lock value and CS
 counts in the same atomic int

On Sun, 18 Jun 2017 10:53:39 -0400 Rich Felker <> wrote:

> > A good way to catch this would be to introduce a struct for the
> > lock (out of scope of this patch, of course).  
> I see reasons for and against that. I'm not strongly against it but
> just making a policy not to poke directly at these locks outside of
> "lock implementation" files (perhaps adding a macro or inline function
> to libc.h to do this instead?) seems like it would work just as well.

I would be in favor of having a struct. This would make reviewing this
code much easier. I also would be much in favor of inline functions or
macros to capture the fastpath of these function. In the orginal
implementation for stdatomic I had that, and it worked quite well:
just an atomic instruction for the fastpath and the function call
overhead only when there is not much to loose, performance wise.

> It was a poor choice to write the above direct a_cas to begin with, I
> think.

I am not sure that I get what you want to say. You mean you would like
to abstract that into something like a __trylock function?


:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: ::

Content of type "application/pgp-signature" skipped

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.