Monitor (synchronization)

Computers often do many tasks at once.

These tasks need to share things. A monitor is a tool that helps them. It uses a lock to stay safe. Only one task can use the tool at a time. This stops mistakes from happening.

Sometimes a task must wait. It waits for something to change. A special signal tells the task to wake up. This helps the computer work well.

It is a smart way to share.

Computers often do many tasks at the same time. These tasks are called threads. Sometimes, threads must share the same object. This can cause mistakes if they do not work together. A monitor is a tool that keeps sharing safe.

A monitor uses a mutex. A mutex is a lock. It makes sure only one thread uses the object at a time. This is called mutual exclusion. When a thread starts a task, it locks the mutex. When the task ends, it unlocks it. This stops errors like data races. A data race is a mistake that happens when threads clash.

Sometimes, a thread cannot finish its task yet. It might need to wait for a change. A monitor uses condition variables to help. A condition variable is a way for a thread to wait.

Instead of checking the object over and over, the thread goes to sleep. This saves power. When the state changes, another thread sends a signal. This signal wakes up the waiting thread. The waiting thread then grabs the lock again to finish its work.

Computers often run many tasks at once. These tasks are called threads. Sometimes, many threads need to use the same piece of information. If they all try to change it at the exact same time, they can cause big mistakes. These mistakes are called data races or logical errors. A monitor is a special tool that keeps this sharing safe. It acts like a manager for a shared object.

A monitor works using two main parts. The first part is called a mutex, which is a type of lock. When a thread wants to use the object, it must first lock the mutex. This creates something called mutual exclusion. This rule means only one thread can use the object at any single moment. While one thread is working, all other threads must wait their turn. Once the thread finishes, it unlocks the mutex so others can enter.

Sometimes, a thread cannot finish its job right away. It might need to wait for something specific to happen first. For example, a thread might need to wait until a list is not empty. Instead of checking the list constantly, which wastes computer power, the thread can sleep. This is where condition variables come in. A condition variable is a way for a thread to wait for a change in state.

When a thread waits on a condition variable, it does something very clever. It temporarily gives up its lock so other threads can enter the monitor. This allows other threads to change the object and make the condition true. Once the change happens, a thread sends a signal. This signal wakes up the sleeping thread. The sleeping thread then tries to grab the lock again to finish its task.

Scientists Per Brinch Hansen and C. A. R. Hoare invented monitors. Brinch Hansen first used them in a language called Concurrent Pascal. Monitors help solve classic problems like the producer-consumer problem. In that problem, one thread makes tasks and another thread uses them. The monitor ensures the maker does not add to a full list. It also ensures the user does not try to take from an empty list. This keeps the whole system running smoothly without errors.

{ "text": "In concurrent programming, a monitor is a synchronization construct. It manages how multiple threads access a shared object's state. Without this control, threads might access data at the same time. This can cause data races or logical errors. A monitor ensures that only one thread uses the object at a time. It also allows threads to wait for specific conditions to be met. This makes monitors a vital tool for building thread-safe objects, classes, or modules.

\n\nThe core of a monitor is mutual exclusion. This means at most one thread can execute a monitor's methods at any time. To enforce this, a monitor uses a mutex, which is a type of lock. When a thread calls a public method, it must first acquire the mutex. This is often described as the thread \"occupying\" the object. If another thread is already using the object, the new thread must wait. Once the first thread finishes its method, it releases the lock. This allows the next waiting thread to enter and begin its task. Without this strict locking, two threads could interfere with each other. For instance, two threads might both see a bank balance of 1000. Both could withdraw 1000 at once, but the balance might only drop by 1000. This creates a serious error in the system's data.\n\nSometimes, mutual exclusion alone is not enough for a program to work. A thread might enter the monitor but find it cannot proceed. For example, a thread might need to remove an item from a list. If the list is currently empty, the thread cannot do its job. A simple solution is \"busy waiting,\" where a thread loops constantly to check the state. However, this wastes a lot of CPU resources. Another option is to unlock the mutex, wait a set amount of time, and then re-lock it. This is difficult because choosing the right wait time is hard. If the time is too short, the CPU is wasted. If it is too long, the program becomes unresponsive.

\n\nTo solve these issues, monitors use condition variables. A condition variable is a queue of threads waiting for a specific state change. It is associated with the monitor's mutex. When a thread needs a condition to be true, it performs a \"wait\" operation. This operation is very specific and must be done atomically. Atomically means the steps happen as one single, uninterrupted unit. During a wait, the thread releases the mutex and goes to sleep. Because the thread no longer holds the lock, other threads can enter the monitor. This allows those other threads to change the state and make the condition true.

\n\nOnce the state changes, a thread can use a \"signal\" or \"notify\" operation. This operation tells the condition variable to wake up a waiting thread. The signaled thread moves from the sleep queue to a ready queue. Once it is awake, the thread must automatically re-acquire the mutex. It cannot resume its work until it has exclusive access to the object again. This careful hand-off prevents race conditions. A race condition happens when the timing of events causes an error. One major risk is a \"missed wakeup.\" This could happen if a thread releases a lock but is interrupted before it actually goes to sleep. If a signal happens during that tiny gap, the thread might sleep forever. The atomic nature of the wait operation prevents this mistake.\n\nA famous example of needing a monitor is the bounded producer/consumer problem. In this scenario, "producer" threads create tasks and put them into a queue. "Consumer" threads take those tasks out of the queue to process them. The queue has a maximum size, which is its bound. If the queue is full, producers must stop and wait for room. If the queue is empty, consumers must stop and wait for tasks. Using a monitor ensures that these accesses are atomic. This prevents the queue from entering an inconsistent state. Without synchronization, a consumer might try to take a task from a queue that just became empty. A producer might try to add a task to a queue that just became full. Both would cause errors in the program.\n\nMonitors were invented by computer scientists Per Brinch Hansen and C. A. R. Hoare. Brinch Hansen first implemented them in his Concurrent Pascal programming language. Their work changed how developers manage complex, multi-threaded systems. By combining mutual exclusion with condition variables, monitors provide a complete solution for thread safety. They allow programmers to write code that is both efficient and reliable. This prevents the waste of CPU power seen in spin-waiting. It also ensures that data remains accurate even when many tasks run at once.", "media": [ "File:Monitor (synchronization)-SU.png", "File:Monitor (synchronization)-Mesa.png", "File:Monitor (synchronization)-Java.png" ] }