As mentioned above, the mutex example was purely for didactic purposes, and definitely not a complete mutex. It was meant to help demonstrate the basics of how a mutex works. Blog post has been updated to clarify this.

care to explain more?

Not GP, but the code in the article passes 'unsigned int mutex' by-value, and then operates on its address (which will potentially be at a different stack address on each invocation, and will certainly be different for different threads.) It won't serve its purpose at all.

To my eye, the code is fundamentally broken in a way that's surprising for an article trying to teach threading, and it's likely confuse someone unfamiliar with these concepts.

The articles code for mutex_lock is this

  mutex_lock(unsigned int mutex)
  {
    while (!cmpxchg(&mutex, UNLOCKED, LOCKED))
      futex(&mutex, FUTEX_WAIT, LOCKED);
  }

Now consider what happens if someone calls it

  volatile unsigned int my_mutex = UNLOCKED;
  mutex_lock(my_mutex);
  ...
  mutex_unlock(my_mutex);

my_mutex is copied into the mutex parameter. The mutex parameter is updated to locked. mutex_lock exits, which destroys the mutex variable. my_mutex still has the variable UNLOCKED.

Good catch, corrected!

One more...

> We use &mutex as the first argument

ops, fixed, thanks!

Without having looked into any details I assume the parent is saying that the integer passed by value is a flag that is checked periodically and used to trigger a next step or to release a lock.

If it's passed by value it will never change inside the function and whatever is supposed to happen when it changes will never get executed. The integers should be passed by reference so when they change the function receiving them is aware of the update.

Most importantly wake and wait are keyed by address. The waker must provide to futex_wake the same address that the waiter passed to futex_wait to wake it.