3 ms·

A mutex is more than that. That's the entire point of the article. A mutex implementation needs to deal with issues like priority inversion, where higher-prio

by panic 16y ago

A mutex is more than that. That's the entire point of the article. A mutex implementation needs to deal with issues like priority inversion, where higher-priority threads continually interrupt a lower-priority thread holding a naively-implemented mutex, starving any other thread (even a high-priority thread) that needs the resource it protects.

Groxx 16y ago
Which is identical to a binary semaphore. If the low priority thread which decremented the semaphore does not allow others to work while it itself is interrupted - ie, it does not increment when blocked - it has the same problem. The difference, as I've seen it, is that mutexes more often have code to account for lock escalations and shared locks, and sometimes other potential problems, which are deemed unimportant for semaphores because they're used where such things are not needed. It's entirely possible to create a semaphore which does account for these - trivial, even, to make a binary semaphore have everything a mutex has. Similarly, a mutex does not need to have such capabilities to be considered a mutex. All of which is simply meta-behaviors, not things which are part of their definitions. Debating about current implementations is useful only in terms of current implementations, not in defining something's inherent capabilities.
forensic 16y ago
Starvation is equally an issue with semaphores.. how does that make a mutex different?
- panic 16y ago
  First of all, it's not clear to me that priority inversion is an issue with semaphores as normally used. If a high-priority consumer thread is waiting on a low-priority producer thread, there may just be no data ready to be consumed. There's no reason to raise the priority of the producer thread if, for example, it's just waiting for some external input. Second, how would you solve priority inversion for general semaphores? With mutexes, you know what thread is holding the mutex, and can bump its priority correspondingly. With semaphores, there's no guarantee that the same thread that incremented the semaphore will decrement it later.
  - Groxx 16y ago
    "As normally used" is part of the problem. How something is normally used has nothing to do with what it is. General semaphores? I'll easily grant that would be difficult. Not impossible, but likely wasteful and a PITA. Binary semaphores, which is where the debate lies? Store a whoDecremented thread pointer, cleared on increment. Which is functionally identical to Dekker's algorithm[1] and Eisenberg and McGuire's algorithm[2], except they require storage for all possible waiting threads, instead of the single storage of a semaphore. edit: links: [1]: http://en.wikipedia.org/wiki/Dekker%27s_algorithm http://en.wikipedia.org/wiki/Dekker%27s_algorithm [2]: http://en.wikipedia.org/wiki/Eisenberg_McGuire_algorithm http://en.wikipedia.org/wiki/Eisenberg_McGuire_algorithm

by panic 16y ago

Groxx 16y ago

Which is identical to a binary semaphore. If the low priority thread which decremented the semaphore does not allow others to work while it itself is interrupted - ie, it does not increment when blocked - it has the same problem. The difference, as I've seen it, is that mutexes more often have code to account for lock escalations and shared locks, and sometimes other potential problems, which are deemed unimportant for semaphores because they're used where such things are not needed. It's entirely possible to create a semaphore which does account for these - trivial, even, to make a binary semaphore have everything a mutex has. Similarly, a mutex does not need to have such capabilities to be considered a mutex. All of which is simply meta-behaviors, not things which are part of their definitions. Debating about current implementations is useful only in terms of current implementations, not in defining something's inherent capabilities.

forensic 16y ago

Starvation is equally an issue with semaphores.. how does that make a mutex different?

panic 16y ago
First of all, it's not clear to me that priority inversion is an issue with semaphores as normally used. If a high-priority consumer thread is waiting on a low-priority producer thread, there may just be no data ready to be consumed. There's no reason to raise the priority of the producer thread if, for example, it's just waiting for some external input. Second, how would you solve priority inversion for general semaphores? With mutexes, you know what thread is holding the mutex, and can bump its priority correspondingly. With semaphores, there's no guarantee that the same thread that incremented the semaphore will decrement it later.
- Groxx 16y ago
  "As normally used" is part of the problem. How something is normally used has nothing to do with what it is. General semaphores? I'll easily grant that would be difficult. Not impossible, but likely wasteful and a PITA. Binary semaphores, which is where the debate lies? Store a whoDecremented thread pointer, cleared on increment. Which is functionally identical to Dekker's algorithm[1] and Eisenberg and McGuire's algorithm[2], except they require storage for all possible waiting threads, instead of the single storage of a semaphore. edit: links: [1]: http://en.wikipedia.org/wiki/Dekker%27s_algorithm http://en.wikipedia.org/wiki/Dekker%27s_algorithm [2]: http://en.wikipedia.org/wiki/Eisenberg_McGuire_algorithm http://en.wikipedia.org/wiki/Eisenberg_McGuire_algorithm