Effectively pthread_mutex_lock does not thin-lock.

To explain why, and why this is required I can show some kind of workaround like this:

if (!pthread_mutex_trylock(…)) {

// now we have contention
pthread_mutex_lock(…);
}

It is more efficient, I alredy have tested it, but behaviour is different.

pthread_mutex_trylock will never block, so is quite close to perform a single CAS operation. But, what if there was a thread already blocked and owner thread just leaved? You stole the lock.

That is what usually happens with thin-locks: locks are usually stolen. That means that you may be not fair with all threads. That’s the reason because pthread_mutex_lock is not as simple as a thin-lock, they are fair.

But, luckily, you don’t need to be fair: so, welcome efficient thin-locks.

Pretty much all of my code now looks like :

public class ConcurrentClass {
private final Object myLock = new Object();
public void doSomething() {
synchronized (myLock) {
… do stuff that needs locking here…
}
}
}

because if you lock on “this”, other code can mess you around by locking on YOU.

On another note, there were some recent papers about locking improvements to the “thin lock” model in Java1.6 that centered around making fat locks more efficient.
The idea was that most locks tends to be taken again and again on the same thread, so rather than unlocking each time, they move the fat lock into a “locked but available” mode, which optimises for the common case.

One could in principle implement Thin Lock using futex. However, futex is a general purpose primitive and Thin Lock is a very specialized algorithm. We know exactly how monitors are used in Java (and similarly in D), so we can optimize the heck out of it. Futex has essentially two states visible on the outside: zero and non-zero. Thin Lock stores a thread ID and a counter. This is essential for the optimization of the recursive case. For the inflated Fat Lock on Linux we use a pthread lock, which in turn uses a futex, so we do take advantage of its performance.

But there’s more to the D thin lock–I’ll describe it in the next post.

More info: man 7 futex

You only spin the first time you detect contention. This spin is based on a benign race. You keep reading and testing, and if you miss something, you’ll catch up later.

To perform the actual inflation, you have to grab the lock first. If several threads are racing to inflate the lock, one of them will always succeed, and all the other ones will fall back on the fat lock.

Whether the OS mutex is spinning or not is up to the OS, which has more information about what’s optimal. On a multi-core machine I would expect a spin lock with backoff.