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 <
nicolas.cellier.aka.nice at gmail.com>:

> 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.
> The active process will give up control if
> 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.
> 3) or if the acquisition of another semaphore is blocked...
>
> 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 <leves at elte.hu>:
>
>> 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 <nicolas.cellier.aka.nice at gmail.com>
>>> Date: 2015-01-02 21:16 GMT+01:00
>>> Subject: Process scheduling question
>>> To: The general-purpose Squeak developers list <squeak-dev at lists.
>>> squeakfoundation.org>
>>>
>>>
>>> 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...
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150108/9cd834a2/attachment.htm