---------- Forwarded message ---------- From: Nicolas Cellier <[hidden email]> Date: 2015-01-02 21:16 GMT+01:00 Subject: Process scheduling question To: The general-purpose Squeak developers list <[hidden email]> Interestingly, using Transcript in Processes in Squeak/Pharo make them behave as if the scheduler was preemptive, which it is not. I failed to find it...http://stackoverflow.com/questions/27731274/smalltalk-visual-works-concurrency So there must be some sort of wait on a busy Semaphore, but where? |
Transcript >> #endEntry uses the AccessSema semaphore. That method is sent
from #show:. Levente On Wed, 7 Jan 2015, Nicolas Cellier wrote: > > ---------- Forwarded message ---------- > From: Nicolas Cellier <[hidden email]> > Date: 2015-01-02 21:16 GMT+01:00 > Subject: Process scheduling question > To: The general-purpose Squeak developers list <[hidden email]> > > > Interestingly, using Transcript in Processes in Squeak/Pharo make them behave as if the scheduler was preemptive, which it is not. > > http://stackoverflow.com/questions/27731274/smalltalk-visual-works-concurrency > > So there must be some sort of wait on a busy Semaphore, but where? > I failed to find it... > > > > > |
Right, but is there a concurrent use of this semaphore? I mean the active process will acquire AccessSema again and again until it give up control.A process of same priority cannot take control and concurrently preempt AccessSema until then. 1) it explicitely yield (not that many senders) 2) or if a higher priority process take possession of AccessSema. AccessSema is only used by endEntry, so it would mean a higher priority proess is transcripting. I failed to find occurences of 1) and 2) so I was tempted by explanation 3) but also failed to find it... Case of blindness? 2015-01-07 19:33 GMT+01:00 Levente Uzonyi <[hidden email]>: Transcript >> #endEntry uses the AccessSema semaphore. That method is sent from #show:. |
And if you perform endEntry job outside of AccessSema critical:section, then there is still a concurrent write of AA and BB, until some process will bug with an inconsistent state mutation and a hardly recoverable error... So, there is an inversion : AccessSema does not cause concurrency. AccessSema is there to protect from concurrency that happens elsewhere and would cause unconsistent state mutations...2015-01-07 22:37 GMT+01:00 Nicolas Cellier <[hidden email]>:
|
Free forum by Nabble | Edit this page |