4

Is it true that a mutex can only be released from the thread that wait on that mutex? If yes why the mutex behaves like this? So why we say a mutex can work across multiple processes? What is named-mutex and unnamed-mutex? I'm really confused about this issue!

If I want to wait on mutex in a thread and signal it from another thread, what should I do?

moorara
  • 3,897
  • 10
  • 47
  • 60
  • Do you mean the `Mutex` class? It's important to be clear since mutex is a general concept and `System.Threading.Mutex` a concrete instantiation thereof. The docs provide a good description of usage, see: http://msdn.microsoft.com/en-us/library/system.threading.mutex.aspx See also this question for more on condition variables in C# : http://stackoverflow.com/questions/1986055/condition-variables-in-c – Steve Townsend Jun 13 '11 at 14:11

4 Answers4

8

A mutual exclusion semaphore does have to be released by the same thread that obtained it. That's the way they work: a single thread acquires the lock on a resource so it can manipulate it and then, when it's finished, it releases that lock so that other threads may lock it.

The whole point of the "mutual exclusion" bit is that the thread with the lock has total power - only it can release that lock. That still allows the mutex to work across multiple threads because it can be owned by any one of them across its lifetime.

A named mutex allows a single mutex to also work across processes as well as threads. The name is used to allow a separate process to "connect" to an already-created mutex and it can then be used to control access to a resource across all connected processes.

For cross-thread communication like you desire, you're looking at something like a condition variable, which is used to signal threads that a condition has been met - I think the equivalent in .Net is the Monitor, with its Wait and Pulse methods.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • _The whole point of the "mutual exclusion" bit is that the thread with the lock has total power - only it can release that lock_ See [here](https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock#Using_two_mutexes) "This __ requires that a mutex acquired by one thread can be released by another." Are you saying that authors of this article are incompetent? ;) – Andrew Savinykh Nov 22 '17 at 04:51
  • @Andrew, not incompetent, just lax in their terminology. If you allow a mutex to be unlocked by a different thread, it loses its power to protect shared resources. Mutual *exclusion* means exactly that: this resource is mine, go away, you can't have it until I'm done with it. There may be synchronisation primitives that allow an extrnal party to release on your behalf but I would argue they shouldn't be called mutexes but rather `muts` :-) – paxdiablo Nov 22 '17 at 07:50
1

A mutex has ownership - see paxdiablo post. If you want to wait on something in a thread and signal it from another thread, don't use a mutex! Event - OK, condvar-OK, monitor-OK, semaphore-OK, Event-OK, mutex-not OK.

Rgds, Martin

Martin James
  • 24,453
  • 3
  • 36
  • 60
1

You cannot signal a mutex (= Mut-ual Ex-clusion kernel synchronization construct) from any other thread than the one who acquired it.

Paul Michalik
  • 4,331
  • 16
  • 18
0

the short answer is that when the mutex is released (from the owning thread) the other threads will be notified

i.e. all threads doing wait on the mutex will compete over ownership of the mutex and the winner will return from the wait call and continue execution, in ownership of the mutex.

That being the difference of using a mutex from having to coordinate the signals yourself. Did that answer you question or have I misunderstood you?

BR Daniel

Daniel
  • 21
  • 1