Question: I've made a hand-made mutex for my project, but I doubt if it is thread safe...

```
    bool blocked;

    while ( blocked )
    {

    }

    blocked = true;
    ...
    blocked = false;

```

Lets say, thread A passes the while loop and doesn't block the flag in time (doesn't have time to set the flag to `false`) and thread B passes the while loop too!

1. Is it possible? Why?
2. As I get it mutex has the very same principle of work. Why can not this occur in mutex? I've read about atomic operations which can not be interrupted... So the `check-if-mutex-available` and `mutex-block` can not be interrupted, right?

Answer: 
Your code is completely defunct!

The reason is that access to the variable `blocked` is not atomic. Two threads can read it si­mul­ta­ne­ous­ly and decide that the mutex is unlocked, if the two reads happen before the first thread writes out the `true` update and the update propagates to all CPUs.

You need atomic variables and atomic exchange to solve this. The `atomic_flag` type is exactly what you want:

```
#include <atomic>

std::atomic_flag blocked;

while (blocked.test_and_set()) { }  // spin while "true"

// critical work goes here

blocked.clear();                    // unlock

```

(Alternatively, you could use a `std::atomic<bool>` and `exchange(true)`, but the `atomic_flag` is made especially for this purpose.)

Atomic variables do not only prevent the compiler from reordering code that *appears* to be unrelated if this were a single-threaded context, but they also make the compiler generate the necessary code to prevent the CPU itself from reordering instructions in a way that would allow inconsistent execution flow.

In fact, if you want to be slightly more efficient, you can demand a less expensive memory ordering on the set and clear operations, like so:

```
while (blocked.test_and_set(std::memory_order_acquire)) { }  // lock

// ...

blocked.clear(std::memory_order_release);                    // unlock

```

The reason is that you only care about the correct ordering in one direction: a delayed update in the other direction is not very expensive, but requiring sequential consistency (as is the default) may well be expensive.

---

**Important:** The above code is a so-called *spin lock*, because while the state is locked, we do a busy spin (the `while` loop). This is very bad in almost all situations. A kernel-provided mutex system call is a whole different kettle of fish, since it allows the thread to signal the kernel that it can go to sleep and let the kernel deschedule the entire thread. That is almost always the better behaviour.
1. It's possible because the processor can switch from the first thread to the second after entering the loop, but before locking the mutex.
2. It's possible because they use kernel-level operations to ensure that the thread is not switched until a certain operation is complete.

On Windows for instance, you could make a mutex look like [this](http://pastebin.com/n45zL3sC).