2

From what I have learned about Mutexes - they generally provide a locking capability on a shared resources. So if a new thread wants to access this locked shared resource - it either quits or has to continually poll the lock (and wastes processor cycles in waiting for the lock).

However, a monitor has condition variables which provides a more asynchronous way for waiting threads - by putting them on wait queue and thereby not making them consume processor cycles.

Would this be the only advantage of monitors over mutexes (or any general locking mechanism without condition variables) ?

Hari
  • 5,057
  • 9
  • 41
  • 51
  • Is this accurate? As far as I know, all current operating systems put mutex operations onto a wait queue. They're not polling. – Zan Lynx Oct 06 '11 at 01:55
  • @ZanLynx: If not, I fail to see the advantage of using monitors over mutexes. – Hari Oct 06 '11 at 05:52

2 Answers2

5

Mutexes are low level construct. They just provide mutual exclusion and memory visibility/ordering. Monitors, on the other hand, are higher level - they allow threads to wait for an application specific condition to hold.

So, in some cases monitors are just overkill over a simple lock/unlock, but in most cases mutexes alone are not nearly enough - so you see them used with one or more condition variables - conceptually using monitors equivalent.

chill
  • 16,470
  • 2
  • 40
  • 44
1

I think, a monitor locks an object (Multi thread cannot access the object at the same time.) While a mutex locks a process (multi-thread only one can go through the process.)

Healer
  • 290
  • 1
  • 7