- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Monitor>>critical: implementation

by Max Leske

> On 05 Jan 2016, at 13:29, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-05 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > What I donât quite understand is why Monitor doesnât use Semaphore>>critical:. If it did that, then there wouldnât be a problem. The problem only exists because #wait and #signal are explicitly sent by the monitor. > > Monitor is reentral which means that two recursive critical sections in same process should not be blocked. This logic implemented in #enter and #exit methods > I should start using my head again. This is a new yearâ¦ :) Thanks Denis.

Jan. 5, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50511 Home: https://github.com/pharo-project/pharo-core

Jan. 5, 2016

[pharo-project/pharo-core] 37b451: 50511

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 37b4510f6cb328b6f8c46222a65cc445db6d0578 https://github.com/pharo-project/pharo-core/commit/37b4510f6cb328b6f8c46222… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-05 (Tue, 05 Jan 2016) Changed paths: A Athens-Cairo.package/AthensCairoMatrix.class/instance/copying/postCopy.st M Athens-Cairo.package/AthensCairoMatrix.class/instance/private/copyFromMatrix_.st M Athens-Cairo.package/AthensCairoMatrix.class/instance/transformations/restoreAfter_.st A Athens-Cairo.package/AthensCairoMatrixTest.class/README.md A Athens-Cairo.package/AthensCairoMatrixTest.class/definition.st A Athens-Cairo.package/AthensCairoMatrixTest.class/instance/tests/testCopy.st A Athens-Cairo.package/AthensCairoMatrixTest.class/instance/tests/testInverted.st M NativeBoost-Core.package/NativeBoost.class/class/testing/isEnabled.st M Nautilus.package/AbstractNautilusUI.class/instance/icon/classIconFor_.st A SUnit-Core.package/TestCase.class/class/testing/hasTestSelectors.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50510.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50511.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50510.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50511.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-MorphicAdapters.package/MorphicLabelAdapter.class/instance/factory/buildWidget.st Log Message: ----------- 50511 17280 Athens restoreAfter: doesnt work https://pharo.fogbugz.com/f/cases/17280 17308 Only show clickable testIcon for non abstract test classes that has tests https://pharo.fogbugz.com/f/cases/17308 17263 Monkey fails with Exception: PrimitiveFailed: primitive #isEnabled in NativeBoost class failed https://pharo.fogbugz.com/f/cases/17263 17306 MorphicLabelAdapter does not honor initial color https://pharo.fogbugz.com/f/cases/17306 http://files.pharo.org/image/50/50511.zip

Jan. 5, 2016

Re: [Pharo-dev] Monitor>>critical: implementation

by Denis Kudriashov

2016-01-05 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > What I donât quite understand is why Monitor doesnât use > Semaphore>>critical:. If it did that, then there wouldnât be a problem. The > problem only exists because #wait and #signal are explicitly sent by the > monitor. Monitor is reentral which means that two recursive critical sections in same process should not be blocked. This logic implemented in #enter and #exit methods

Jan. 5, 2016

Re: [Pharo-dev] Monitor>>critical: implementation

by Max Leske

> On 05 Jan 2016, at 13:23, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-05 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > You may have a point there. Although the monitor uses a Semaphore #forMutualExclusion, which is a semaphore with one signal. So the case where the semaphore gets signalled without #wait is less likely I think. > > No. It has no relation to incorrect scenarios of semaphore signalling. > #forMutualExclusion just make semaphore free to use. So first caller of #wait will grab lock. And others will wait. > Two times signalled semaphore will allow two critical sections be performed simultaneously which should not happen True >

Jan. 5, 2016

Re: [Pharo-dev] Monitor>>critical: implementation

by Denis Kudriashov

2016-01-05 12:59 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > You may have a point there. Although the monitor uses a Semaphore > #forMutualExclusion, which is a semaphore with one signal. So the case > where the semaphore gets signalled without #wait is less likely I think. > No. It has no relation to incorrect scenarios of semaphore signalling. #forMutualExclusion just make semaphore free to use. So first caller of #wait will grab lock. And others will wait. Two times signalled semaphore will allow two critical sections be performed simultaneously which should not happen

Jan. 5, 2016

Re: [Pharo-dev] Monitor>>critical: implementation

by Max Leske

> On 05 Jan 2016, at 11:17, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > Here is Monitor code: > > critical: aBlock > ^[ > self enter. > aBlock value] > ensure: [self exit]. > > Now look at Semaphore comment and implementation: > > We need to catch eventual interruptions very carefully. > The naive approach of just doing, e.g.,: > self wait. > aBlock ensure: [self signal]. > will fail if the active process gets terminated while in the wait. > However, the equally naive: > [self wait. > aBlock value] ensure: [self signal]. > will fail too, since the active process may get interrupted while > entering the ensured block and leave the semaphore signaled twice. > > critical: aBlock > | blockValue caught | > caught := false. > [ > caught := true. > self wait. > blockValue := mutuallyExcludedBlock value > ] ensure: [caught ifTrue: [self signal]]. > ^blockValue > > So Monitor can be corrupted when process which enters critical section will be terminated. "Ensure block" can signal mutex which was not in waiting mode. Which means that next critical call in another Process will be not guarded. > > What you think? Is my investigation right? > > I look at users of Monitor. Most time it is used like Mutex. Only #critical: method is used. So Monitor can be replaced by Mutex at that places. And possible problem will be fixed. > > SharedQueue is classic example for Monitor usage. Interesting is anybody got problems with it? You may have a point there. Although the monitor uses a Semaphore #forMutualExclusion, which is a semaphore with one signal. So the case where the semaphore gets signalled without #wait is less likely I think. What I donât quite understand is why Monitor doesnât use Semaphore>>critical:. If it did that, then there wouldnât be a problem. The problem only exists because #wait and #signal are explicitly sent by the monitor.

Jan. 5, 2016

small refactor on files.pharo.org

by Esteban Lorenzano

I move old VMs from files.pharo.org/vm <http://files.pharo.org/vm> to files.pharo.org/vm/old <http://files.pharo.org/vm/old> because it was confusing and some students were lost (Stef too :P). cheers, Esteban

Jan. 5, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

2016-01-04 18:51 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Is this meant to be part of the main distribution? I don't know. People should decide it. To me it is normal to get explicit dependency in configuration.

Jan. 5, 2016

Monitor>>critical: implementation

by Denis Kudriashov

Hello. Here is Monitor code: critical: aBlock > ^[ > self enter. > aBlock value] > ensure: [self exit]. Now look at Semaphore comment and implementation: > We need to catch eventual interruptions very carefully. > The naive approach of just doing, e.g.,: > self wait. > aBlock ensure: [self signal]. > will fail if the active process gets terminated while in the wait. However, the equally naive: > [self wait. > aBlock value] ensure: [self signal]. > will fail too, since the active process may get interrupted while > entering the ensured block and leave the semaphore signaled twice. > > critical: aBlock > | blockValue caught | > caught := false. > [ > caught := true. > self wait. > blockValue := mutuallyExcludedBlock value > ] ensure: [caught ifTrue: [self signal]]. > ^blockValue So Monitor can be corrupted when process which enters critical section will be terminated. "Ensure block" can signal mutex which was not in waiting mode. Which means that next critical call in another Process will be not guarded. What you think? Is my investigation right? I look at users of Monitor. Most time it is used like Mutex. Only #critical: method is used. So Monitor can be replaced by Mutex at that places. And possible problem will be fixed. SharedQueue is classic example for Monitor usage. Interesting is anybody got problems with it?

Jan. 5, 2016