<div dir="ltr"><div>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...<br><br></div>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...<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-07 22:37 GMT+01:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Right, but is there a concurrent use of this semaphore?<br></div>I mean the active process will acquire AccessSema again and again until it give up control.<br>A process of same priority cannot take control and concurrently preempt AccessSema until then. </div>The active process will give up control if<br>1) it explicitely yield (not that many senders)<br>2) or if a higher priority process take possession of AccessSema.<br> AccessSema is only used by endEntry, so it would mean a higher priority proess is transcripting.</div>3) or if the acquisition of another semaphore is blocked...<br></div><div><div><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">I failed to find occurences of 1) and 2) so I was tempted by explanation 3) but also failed to find it...<br></div><div class="gmail_extra">Case of blindness?<br></div><div><div class="h5"><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">2015-01-07 19:33 GMT+01:00 Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Transcript >> #endEntry uses the AccessSema semaphore. That method is sent from #show:.<span><font color="#888888"><br>
<br>
Levente</font></span><div><div><br>
<br>
On Wed, 7 Jan 2015, Nicolas Cellier wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
---------- Forwarded message ----------<br>
From: Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@<u></u>gmail.com</a>><br>
Date: 2015-01-02 21:16 GMT+01:00<br>
Subject: Process scheduling question<br>
To: The general-purpose Squeak developers list <<a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.<u></u>squeakfoundation.org</a>><br>
<br>
<br>
Interestingly, using Transcript in Processes in Squeak/Pharo make them behave as if the scheduler was preemptive, which it is not.<br>
<br>
<a href="http://stackoverflow.com/questions/27731274/smalltalk-visual-works-concurrency" target="_blank">http://stackoverflow.com/<u></u>questions/27731274/smalltalk-<u></u>visual-works-concurrency</a><br>
<br>
So there must be some sort of wait on a busy Semaphore, but where?<br>
I failed to find it...<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div></div></div></div></div></div></div></div>
</blockquote></div><br></div></div></div></div>