As promised, I posted a blog comparing the thin lock to futex. Please vote it on reddit: http://www.reddit.com/comments/6z4sv/ .

"Bartosz Milewski" <bartosz@relisoft.com> wrote in message news:g9jvui$nbs$1@digitalmars.com...
> As promised, I posted a blog comparing the thin lock to futex. Please vote it on reddit: http://www.reddit.com/comments/6z4sv/ .

Early on you say this...

"Unlock tests if the futex variable is equal to one (we are the owner, and nobody is waiting). If true, it sets it to zero. This is the fast-track common-case execution that doesn't make any futex calls whatsoever."

But the futex code you list later in the blog does this....

// we own the lock, so it's either 1 or 2
      if (atomic_decrement(&_word) != 1)

So does the futex actualy need/use an atomic for unlocking?

If it does then that makes it a great deal slower than a thin lock as that typicaly doesnt require an atomic for the unlock. As im sure you're aware, CAS and such like cost around 120..160 cycles on most cpus, so having an algorythm that cuts their usage in half is a big avantage.

So I'd be touting that as good reason to use thin locks. :-)

Jb wrote:
> "Bartosz Milewski" <bartosz@relisoft.com> wrote in message news:g9jvui$nbs$1@digitalmars.com...
>> As promised, I posted a blog comparing the thin lock to futex. Please vote it on reddit: http://www.reddit.com/comments/6z4sv/ .
> 
> Early on you say this...
> 
> "Unlock tests if the futex variable is equal to one (we are the owner, and nobody is waiting). If true, it sets it to zero. This is the fast-track common-case execution that doesn't make any futex calls whatsoever."
> 
> But the futex code you list later in the blog does this....
> 
> // we own the lock, so it's either 1 or 2
>       if (atomic_decrement(&_word) != 1)
> 
> So does the futex actualy need/use an atomic for unlocking?

That implementation does.  However, I think it could be replaced by an unordered atomic load followed by a set with "release" semantics on most modern architectures.  On (non-AMD) x86, this should mean no explicit synchronization for the unlock() routine.

> If it does then that makes it a great deal slower than a thin lock as that typicaly doesnt require an atomic for the unlock. As im sure you're aware, CAS and such like cost around 120..160 cycles on most cpus, so having an algorythm that cuts their usage in half is a big avantage.

Definitely.


Sean