On Fri, Jan 10, 2020 at 2:01 PM Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Steph,
On Jan 10, 2020, at 12:42 PM, ducasse <stepharo@netcourrier.com> wrote:
Yes this is why in my chapter on Exception I show the VM code while some people told me that it was not interesting. And this is why in the current chapter on semaphore I have a section on the implementation. Now it does not mean that the we cannot have a higher view too :).
Indeed. Note that now we have two improvements supported by the VM over the blue book scheduler & synchronization primitives.
Oops! I forgot to mention the other improvement. That is the ability of the scheduler to add a process to the front of a particular run queue when a process is preempted, not to the back of its run queue as is specified (erroneously) in the original Smalltalk-80 specification. Why is this erroneous? Smalltalk has a real-time preemptive-across-priorities, cooperative-within-priorities scheduling model. No process at the same priority as the active process can preempt the active process. Instead it must wait until the active process yields (which moves a process to the back of its run queue, allowing all other runnable processes at its priority a chance to run until it will run again), is suspended (on a semaphore or mutex), or explicitly suspends (via the suspend primitive). So when the original scheduler puts a process at the end of its run queue when a higher priority process preempts it that introduces an implicit yield, which violates the contract, a contract that can be used to implement cheapjack-free mutual exclusion between processes of the same priority. So the improvement, selected by a vm flag, is to cause preemption to add a process to the front of its run queue, maintaining the order and preserving the contract. _,,,^..^,,,_ best, Eliot