Re: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

2016-06-01 Thread Mateusz Guzik
On Fri, May 27, 2016 at 04:21:11PM -0700, John Baldwin wrote: > On Friday, May 27, 2016 09:17:01 PM Mateusz Guzik wrote: > > Hello there, > > > > quite some time ago I posted a trivial patch to locking primitives. What > > they do is the inline part tries an atomic op and if that fails the > > act

Re: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

2016-05-27 Thread John Baldwin
On Friday, May 27, 2016 09:17:01 PM Mateusz Guzik wrote: > Hello there, > > quite some time ago I posted a trivial patch to locking primitives. What > they do is the inline part tries an atomic op and if that fails the > actual function is called, which immediately tries the same op. > > The obvi

Re: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

2016-05-27 Thread Eric van Gyzen
On 05/27/16 02:17 PM, Mateusz Guzik wrote: > Hello there, > > quite some time ago I posted a trivial patch to locking primitives. What > they do is the inline part tries an atomic op and if that fails the > actual function is called, which immediately tries the same op. > > The obvious optimisation

[PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

2016-05-27 Thread Mateusz Guzik
Hello there, quite some time ago I posted a trivial patch to locking primitives. What they do is the inline part tries an atomic op and if that fails the actual function is called, which immediately tries the same op. The obvious optimisation checks for the availability of the lock first. There