Is blocking on mutex equivalent to empty while cycle?

I'm writing a concurrency application for the iPhone. I wonder if this code:

while(!conditionBoolean)
{
    // do nothing
    // until another thread makes this variable true.
}

makeWork();

Is equivalent to the following:

[lock lock];       // this lock is locked by another thread
       开发者_如何学运维            // causing the current to block until it's unlocked

[lock unlock];
 makeWork();

If it's not, what's the difference?

Thank you.

---

You should prefer the second, the first will produce a tight loop and delay or maybe even prevent the variable being set in the way you want/expect. At the very least you would have to introduce a delay in that loop, a sleep of some kind.

Better still would be to wait on a signalling primitive for the work to complete, which then gets signalled by the other thread - the design is then deterministic, versus depending on a mutex or state variable that some other thread might lock or modify before you get your chance. In general, it's better for a multi-threaded design to be event-driven (push model), not check shared state opportunistically (pull model).

---

My understanding of mutexes is that the lock can occur in less cycles, so for example it's possible that while you read the conditionboolean to become true, it's possible that another thread could still change it to true while you're reading it, and another goes to false before you read it again. This turns into a race condition, which the mutex locking would hope to avoid. Also this could cause your code not to be the "next in line" if you have numerous functions with a similar while loop.