From 060be212709c4f34b55ebb4a27d625dd39b871f7 Mon Sep 17 00:00:00 2001 From: Marco Realacci Date: Fri, 21 Mar 2025 19:35:05 +0100 Subject: [PATCH] vault backup: 2025-03-21 19:35:05 --- Concurrent Systems/notes/4b - Monitors.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Concurrent Systems/notes/4b - Monitors.md b/Concurrent Systems/notes/4b - Monitors.md index 8e03315..df7fc00 100644 --- a/Concurrent Systems/notes/4b - Monitors.md +++ b/Concurrent Systems/notes/4b - Monitors.md @@ -1,7 +1,7 @@ Semaphores are hard to use in practice because quite low level Monitors provide an easier definition of concurrent objects at the level of Prog. Lang. >[!note] MUTEX ->Every operation in a monitor is done with mutual exc +>Monitors provide mutual exclusion. Operations in a monitor are done with mutual exclusion. Inter-process synchronization is done through *conditions*, which are objects that provide the following operations: - ***wait*:** the invoking process suspends, enters into the condition's queue, and releases the mutex on the monitor @@ -34,7 +34,8 @@ Of course, `signal()` will have no effect on the last process who calls it. - A semaphore MUTEX init at 1 (to guarantee mutex in the monitor) - For every condition C, a semaphore SEMC init at 0 and an integer $N_{C}$ init at 0 (to store and count the number of suspended processes on the given condition) - A semaphore PRIO init at 0 and an integer $N_{PR}$ init at 0 (to store and count the number of processes that have performed a signal, and so have priority to re-enter the monitor) ->[!note]Operations + +>[!note] Operations >Every monitor operation starts with `MUTEX.down()` and ends with `if NPR > 0 then PRIO.up() else MUTEX.up()` ```