Hi Stef, On Sun, 12 Jan 2020 at 11:28, ducasse <steph...@netcourrier.com> wrote: > > Hi alistair > > > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. > 'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1. > but I would like explain clearly but it depends on the semantics of signal. > > > The way this is phrased seems to imply that 'p2' will always be > displayed before 'p1', however in Pharo this is not guaranteed (when > the processes are at the same priority, as they are this example). > > > No this is not what I implied. > I will reread and rephrase the chapters. > > As Eliot implied in another reply, Pharo has #processPreemptionYields > set to true, which means that any time a higher priority process > preempts, the current process will be moved to the back of the queue. > > > Yes this is explained in the next chapter. > What you should see is that we cannot explain everything in a single chapter. > At least I cannot.
Agreed. Maybe just a footnote indicating that process scheduling will be explained in later chapters. > So in the case above, after p2 signals the semaphore, if a timer was > delivered or keystroke pressed, p2 would be suspended and moved to the > back of the queue. When the timer / keystroke / etc. had finished > processing p1 would be at the front of the queue and would complete > first. > > Since time and input events are (for practical purposes) unpredictable > it means that the execution order of processes at a given priority is > also unpredictable. > > While this isn't likely to happen in the example above, I have seen it > regularly with TaskIt and multiple entries being run concurrently. > > I agree with Eliot that changing #processPreemptionYields to true by > default would be an improvement in Pharo. It would make it easier to > predict what is happening in a complex environment. As Sven kindly pointed out, I meant to say set #processPreemptionYields to false. > If this would be that easy. :) > Now what would be a consequence: we should revisit all the processes of the > system > and understand if/where they should yield. Because now there is an implicit > yield. > So in an ideal world the new semantics is probably better. Now are we ready > to get new bugs > and chase them when an old logic like for example an hidden process in > calypso worked > under the assumption that it was implicitly yielding after preemption? > This is the question that we asked ourselves and we do not really know. > So far Pharo worked this way during 12 years with this semantics (I does not > mean that we cannot > change because of our Motto - but the point is to understand the impact and > control). > Contrary to what people may think we are not changing without assessing > impact. > So to us this is not an easy decision (while doing it take one single line of > one assignment). I also wasn't implying that we just go ahead and change it. But if it is a possibility then I'll try changing it in my image and see how it helps with tracking down inter-process interactions that we're currently experiencing, and if it does introduce any showstopper issues. Cheers, Alistair
