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? Thanks Jens -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::