Hi Sven, In line below...
Cheers, Alistair (on phone) On Sun., 12 Jan. 2020, 13:00 Sven Van Caekenberghe, <s...@stfx.eu> wrote: > > Hi Alistair, > > > On 12 Jan 2020, at 09:33, Alistair Grant <akgrant0...@gmail.com> wrote: > > > > > > 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. > > I don't understand, in your second paragraph you say 'Pharo has > #processPreemptionYields set to true' and now you say it should become the > default. Is that already the case or not then ? Oops, typo, sorry. I meant to say 'false'. (I shouldn't ever reply in a hurry). > > > Running the following variant, and then typing in to another window, > > demonstrates the behaviour: > > I am not sure what you want to demonstrate: that it is totally random > depending on external factors ;-) ? If processPreemptionYields false the output should be: ... p2 p1 p2 p1 p2 p1 ... i.e. it is regular. What we're actually seeing is: ... 'p1' 'p2' 'p1' 'p2' 'p2' ... Which showing that p2 might get to signal multiple times before p1 gets to complete a single loop. > Which is pretty bad: how should semaphores be used (safely) ? What are good > examples of real world correct semaphore usage ? Given a set of processes at the same priority the amount of time allocated to any one of the processes is unpredictable. All the semaphore usage is working as described. My point wasn't that the semaphores are being used incorrectly, but that you can't make assumptions about the order in which processes will complete if they are CPU bound. > Right now, all the explanations around scheduling of processes and their > priorities make it seem as if the answer is 'it all depends' and 'there is no > way to be 100% sure what will happen'. The semaphore operations are clear, but which process, within a single process priority, gets the most CPU time is less so. HTH, Alistair
