Q:

What happens if two theads lock a mutex concurrently?

I'm interested in how a mutex works. I understand their purpose as every website I have found explains what they do but I haven't been able to understand what happens in this case:

There are two threads running concurrently and they try to lock the mutex at the same time.

This would not be a problem on a single core as this situation could never happen, but in a multi-core system I see this as a problem. I can't see any way to prevent concurrency problems like this but they obviously exist.
Thanks for any help

A:

It's not possible for 2 threads to lock a system wide Mutex, one will lock it the other will be blocked.

The semantics of mutex/lock! ensure that only one thread can execute
  beyond the lock call at any one time. The first thread that reaches
  the call acquires the lock on the mutex. Any later threads will block
  at the call to mutex/lock! until the thread that owns the lock
  releases the lock with mutex/unlock!.

In terms of how it's possible to implement this, take a look test-and-set.

In computer science, the test-and-set instruction is an instruction
  used to write to a memory location and return its old value as a
  single atomic (i.e., non-interruptible) operation. If multiple
  processes may access the same memory, and if a process is currently
  performing a test-and-set, no other process may begin another
  test-and-set until the first process is done. CPUs may use
  test-and-set instructions offered by other electronic components, such
  as dual-port RAM; CPUs may also offer a test-and-set instruction
  themselves.
The calling process obtains the lock if the old value was 0. It spins
  writing 1 to the variable until this occurs.

A:

A mutex, when properly implemented, can never be locked concurrently. For this, you need some atomic operations (operations that are guaranteed to be the only thing happening to an object at one moment) that have useful properties.
One such operation is xchg (exchange) in the x86 architecture. For instance xchg eax, [ebp] will read the value at the address ebp, write the value in eax to the address ebp and then set eax to the read value, while guaranteeing that these actions won't be interleaved with concurrent reads and writes to that address.
Now you can implement a mutex. To lock, load 1 into eax, exchange eax with the value of the mutex and look at eax. If it's 1, it was already locked, so you might want to sleep and try again later. If it's 0, you just locked the mutex. To unlock, simply write a value of 0 to the mutex.
Please note that I'm glossing over important details here. For instance, x86's xchg is atomic enough for pre-emptive multitasking on a single processor. When you're sharing memory between multiple processors (e.g. in a multi-core system), it won't be enough unless you use the lock prefix (e.g. lock xchg eax, [ebp], rather than xchg eax, [ebp]), which ensures that only one processor can access that memory while the instruction is executed.

