What is a monitor, mutex, and semaphore? Are they the same thing or different things?
It's just written differently everywhere. And I can not understand what each of these concepts actually means. For example, the same Eckel has such lines about it:
To solve the problem of thread contention, virtually all multithreaded schemes synchronize access to shared resources. This means that only one thread can access a shared resource at a time. This is most often done by placing a code snippet in a section locks so that only one thread can pass through this code fragment at a time. Because such a lock clause has the effect of mutual exclusion, this mechanism is often referred to as mutex (MUTual Exclusion).
Java has built-in support for conflict prevention in the form of the synchronized keyword. When a thread wants to execute a fragment protected by the word synchronized, it checks whether the semaphore is available, accesses the semaphore, executes the code, and frees up semaphore.
I myself read in an article (and so far I adhere to this understanding) that a mutex is an object that is associated with each object in Java, and which can take two states: busy and free. And about the monitor in the same article, it was written that this is a special mechanism (in fact, a piece of code), which, using a mutex, regulates the access of threads to a certain block of code (that is, it is responsible for capturing the thread of the resource, and allows only one given the thread (which has captured the mutex) goes through this code block protected by the monitor; accordingly, the monitor does not allow other threads to occupy this resource and this code block; and when the thread exits this code block, the monitor releases the mutex and allows other threads to enter this code block). Is this the correct understanding?
And what exactly do these concepts mean in Java?
1 answers
In general, we can assume that mutex is a special case of semaphore. The semaphore works simply - it has a certain initial number-a counter. Each time a thread "captures" a semaphore, this number is reduced by one. If it is equal to zero or less than zero, the semaphore is locked (that is, roughly speaking, the code stops at the moment when the semaphore is captured). Each time the semaphore is released, this counter is incremented by one. And if it then turns out to be greater than zero, then which one then an arbitrary thread that "hangs on the semaphore capture" will be sent a wake-up signal and it will be able to continue working (naturally, again reducing the counter value).
The most obvious example of a semaphore is download managers-we add a lot of files to download, but limit the number of simultaneous jumps.
And a mutex is just a semaphore that is initialized with the initial number 1. Therefore, only one thread can capture it. But as always, there are exceptions. There are the so-called read-write mutexes (RWLock). These mutexes can be captured on read and on write. And if many threads can capture a read, then only one can capture a write (yes, and at this point no one else can read).
That a mutex is an object that is associated with every object in Java, and that can take two states: busy and free.
This is almost close to the truth. Yes, in java, the Object class has a mutex type field. And all the heirs (read all the other classes) they also receive a personal mutex. if the method is marked with the word syncronized, then it simply wraps its call in this mutex. That is, if you call syncronized methods on the same object from different threads, mutex will not allow them to be executed in parallel. But for different objects (even the same type) it doesn't work anymore.