036 — Synthèse sur les moniteurs en Java

036 — Synthèse sur les moniteurs en Java


Hello everyone, in this sequence
we’re going to review monitors in Java. I think at this stage you’ve understood that there was the pure notion of monitors as it was defined by Hoare in 74 and then there’s the implementation that’s done in Java. just like there are other implementations done in other languages that aren’t 100.0% identical. First, let’s look at what we have in the Hoare monitor as we say in a past sequence. First we have the context. And we basically have the context we want. All the data structures that you want to include that you need in order to manage the monitor elements and produce the necessary synchronisations. Then you have a few manipulation primitives where you’re sure to only have one
active execution path. Whether it’s a thread, a process, or something else, there’s only one active one. If there are several in these primitive codes, there is always N – 1 at least that are blocked on a wait() or, as we saw, on a signal(). Finally, there’s the notion of conditions that
eventually let you manage its execution paths with three operations: wait, empty, et signal. If you find the Hoare papers that’s how it’s defined. So there’s also a very important
point in the Hoare monitor, it’s that when an execution path does a signal, it will be suspended but it will promptly start again when faced with execution paths that are either
waiting to enter a procedure to be processed because everyone is suspended, or could be woken up by a signal. After a wait(), we do it like that, we’ll guarantee the absenve of deadlocks. So those are the elements that are
extremely important in the monitor like it was designed by Hoare in 74. Java’s interpretation in the
Object class, well, there are some elements that line up, and some that are different. So still in the context, we’re still putting what we want. The manipulation primitives, actually, if we want to guarantee the unique execution path, the user has to check it, and so we’re going to put some synchronized-s on objects, for example, or in the methods. We’ll find the notion of wait(). We won’t find the notion of empty, so we’re going to have to make do, and we have the signal that corresponds with notify(), knowing that the signal in the real monitor makes the task wait, which sends the signal to execute the task, which is woken up and at that moment the signal will be restarted right away while in Java, notify() will place a flag which will make the thread which was suspended, change to ready, and as a result it can have the processor again. There are differences and you have to know that there are other implementations for Hoare monitors which have other differences, for example in Ada, implementing the monitor in Ada is no longer completely pure. There are differences. But obviously not the same ones as in Java, or else it wouldn’t be fun. And also the implementations in programming libraries that you can use in the languages which are sequential languages, there you also have a few variations. We’ll see in Java that there’s another monitor
implementation that’s more complete, and we’ll see in
later sequences that it’s the notion of ReentrantLock. So that’s an important point because
actually in Java we have a kind of monitor, a sort of locking system, but it’s a fairly primitive monitor, while in ReentrantLock, you have the association of much purer conditions compared to what Hoare defined, to an entity that lets up manage them in a group. While if, for example, I want several queues I can block my processes on several conditions, on several semantics, for example, I’m blocked on read mode, and I’m
blocked on write mode, that can happen, if, for example, I have a producer/consumer system with a restricted message queue when consumers aren’t consuming, I have to be able to block the producers so they don’t write in the data that got lost. And so that’s a little more complicated to implement because you’re going to need two different objects, and in the end there’s
not always a relationship, you’re the one who’ll make the relationship. That sometimes requires you to have synchronized-s in synchronized-s, which isn’t at all impossible, but it’s never very comfortable. To conclude, don’t forget what I’m calling the risks of the job, especially the notion of deadlocks, livelocks, you could also refer to it as starvation, but I like the term livelock, which is literally what it means,
especially when you compare deadlocks to livelocks, and then you also have to pay attention to the inconsistencies in the critical resources, or else you can have a nervous breakdown, like
you see here. Thanks for watching, see you soon.

Leave a Reply

Your email address will not be published. Required fields are marked *