January 2020 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] about signal

by ducasse

> ducasse wrote >> It was so simple that I preferred to do it myself so like that I will look >> like a great Pharo contributor. > > :) :) Sometimes I do not know if my humour is strange or not :) But strange humour is better than no humour :) Stef PS: I read too many gary larson comics to be safe :)

Jan. 10, 2020

Re: [Pharo-dev] about signal

by Sean P. DeNigris

ducasse wrote > It was so simple that I preferred to do it myself so like that I will look > like a great Pharo contributor. :) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 10, 2020

Re: [Pharo-dev] about signal

by ducasse

Yes this is why in my chapter on Exception I show the VM code while some people told me that it was not interesting. And this is why in the current chapter on semaphore I have a section on the implementation. Now it does not mean that the we cannot have a higher view too :). > On 10 Jan 2020, at 18:29, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > For example, whether a Semaphore would queue waiting process by order of registration (thru a linked list for example) or by order of priority (thru a Heap for example), would completely change its behavior. > So isn't that kind of implementation detail SUPER important, especially when hidden in VM? > > Also, describing HOW it works is very often used as a mean to explain (and make understand) a higher level feature. > IMO, understanding a feature from one implementation is as useful as understanding a feature by examples of usage. > Even when implementation is plain Smalltalk, it's already an added value to give main guidelines to help reading code (see this particular class or message for understanding the core...), so when it's in VM... > > Le ven. 10 janv. 2020 Ã 12:59, Danil Osipchuk <danil.osipchuk(a)gmail.com <mailto:danil.osipchuk@gmail.com>> a Ã©crit : > I didn't claim expertise on the subject (although I use semaphores extensively), nor its simplicity, nor that the implementation description should be the only guide on its usage (hence 'to add..., how it works' wording) > Said that, to me it is the case, when a clear description of what is going on aids a lot. Instead of trying to define some rules and scenarios abstractly - to help a user to reason about the system behavior (isn't Stef was willing to look into VM code for this reason?). > > To me both scenarios of Stef could be explained that in first case the 'signal' process is not getting preempted by the 'wait' process of the same priority, while in second the preemption happens upon return from primitive (hopefully my memory serves me well and my understanding is correct). > > A tangent note on comments in general -- I've noticed more than once, that people tend to produce far clearer descriptions in exchanges like this -- when discussing matter with others. > When a person is in documentation/comment writing mode he/she is sort of tenses up in a formal state and often produces something not very helpful. Current class comment of Semaphore is a perfect example, if I were not familiar with the concept from other sources, I would not be able to make any sense of it. So, I would suggest to use opportunities like this to improve comments/docs when a bit of knowledge shows up in a discussion. > > > > regards, > Danil > > Ð¿Ñ, 10 ÑÐ½Ð². 2020 Ð³. Ð² 13:09, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > Actually, it is just a, albeit concise, description of how Semaphores are implemented. > > It does not help much in understanding them, in learning how they can/should be used, for what purposes and how code behaves. > > Understanding of Process, priorities and Scheduling are also needed for a more complete understanding. > > This is not a simple subject. > > Read https://en.wikipedia.org/wiki/Semaphore_(programming) <https://en.wikipedia.org/wiki/Semaphore_(programming)> and see how well you understand the subject. > > In short, it does not answer Stef's concrete question(s). > > > On 10 Jan 2020, at 06:30, Danil Osipchuk <danil.osipchuk(a)gmail.com <mailto:danil.osipchuk@gmail.com>> wrote: > > > > Maybe to add this into the class comment, this is the most concise and clear description of how it works i've ever seen > > > > Ð¿Ñ, 10 ÑÐ½Ð². 2020 Ð³., 8:13 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: > > > > > > On Thu, Jan 9, 2020 at 5:03 AM ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: > > Hi > > > > I wanted to explain > > > > | semaphore p1 p2 | > > semaphore := Semaphore new. > > p1 := [ semaphore wait. > > 'p1' crTrace ] fork. > > > > p2 := [semaphore signal. > > 'p2' crTrace ] fork. > > > > displays p2 and p1. > > but I would like explain clearly but it depends on the semantics of signal. > > > > > > - ==p1== is scheduled and its execution starts to wait on the semaphore, so it is removed from the run queue of the scheduler and added to the waiting list of the semaphore. > > - ==p2== is scheduled and it signals the semaphore. The semaphore takes the first waiting process (==p1==) and reschedule it by adding it to the end of the suspended lists. > > > > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 will start to run until something else happens after the execution of p1 := [...] fork. p2 := [...] fork. So for example, if there is Processor yield then p1 can start to run. > > > > So you need to add code to your example to be able to determine what will happen. The easiest thing would be to delay long enough that both can run. 1 millisecond is more than enough. > > > > Now this sentence "The semaphore takes the first waiting process (==p1==) and reschedule it by adding it to the end of the suspended lists.â is super naive. Is the semaphore signalling scheduled? or not? > > > > I would say these three things, something like this: > > > > "A semaphore is a queue (implemented as a linked list) and an excess signals count, which is a non-negative integer. On instance creation a new semaphore is empty and has a zero excess signals count. A semaphore created for mutual exclusion is empty and has an excess signals count of one." > > > > "When a process waits on a semaphore, if the semaphore's excess signals count is non-zero, then the excess signal count is decremented, and the process proceeds. But if the semaphore has a zero excess signals count then the process is unscheduled and added to the end of the semaphore, after any other processes that are queued on the semaphore." > > > > "When a semaphore is signaled, if it is not empty, the first process is removed from it and added to the runnable processes in the scheduler. If the semaphore is empty its excess signals count is incremented. > > > > Given these three statements it is easy to see how they work, how to use them for mutual exclusion, etc. > > > > > > > > signal > > "Primitive. Send a signal through the receiver. If one or more processes > > have been suspended trying to receive a signal, allow the first one to > > proceed. If no process is waiting, remember the excess signal. Essential. > > See Object documentation whatIsAPrimitive." > > > > <primitive: 85> > > self primitiveFailed > > > > "self isEmpty > > ifTrue: [excessSignals := excessSignals+1] > > ifFalse: [Processor resume: self removeFirstLink]" > > > > > > I wanted to know what is really happening when a semaphore is signalled. > > Now resume: does not exist on Processor. > > > > I will look in the VM code. > > > > > > S > > > > > > > > > > > > S. > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > >

Jan. 10, 2020

Re: [Pharo-dev] about signal

by ducasse

Done. https://github.com/pharo-project/pharo/issues/5466 It was so simple that I preferred to do it myself so like that I will look like a great Pharo contributor. > On 10 Jan 2020, at 06:30, Danil Osipchuk <danil.osipchuk(a)gmail.com> wrote: > > Maybe to add this into the class comment, this is the most concise and clear description of how it works i've ever seen > > Ð¿Ñ, 10 ÑÐ½Ð². 2020 Ð³., 8:13 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: > > > On Thu, Jan 9, 2020 at 5:03 AM ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. > 'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1. > but I would like explain clearly but it depends on the semantics of signal. > > > - ==p1== is scheduled and its execution starts to wait on the semaphore, so it is removed from the run queue of the scheduler and added to the waiting list of the semaphore. > - ==p2== is scheduled and it signals the semaphore. The semaphore takes the first waiting process (==p1==) and reschedule it by adding it to the end of the suspended lists. > > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 will start to run until something else happens after the execution of p1 := [...] fork. p2 := [...] fork. So for example, if there is Processor yield then p1 can start to run. > > So you need to add code to your example to be able to determine what will happen. The easiest thing would be to delay long enough that both can run. 1 millisecond is more than enough. > > Now this sentence "The semaphore takes the first waiting process (==p1==) and reschedule it by adding it to the end of the suspended lists.â is super naive. Is the semaphore signalling scheduled? or not? > > I would say these three things, something like this: > > "A semaphore is a queue (implemented as a linked list) and an excess signals count, which is a non-negative integer. On instance creation a new semaphore is empty and has a zero excess signals count. A semaphore created for mutual exclusion is empty and has an excess signals count of one." > > "When a process waits on a semaphore, if the semaphore's excess signals count is non-zero, then the excess signal count is decremented, and the process proceeds. But if the semaphore has a zero excess signals count then the process is unscheduled and added to the end of the semaphore, after any other processes that are queued on the semaphore." > > "When a semaphore is signaled, if it is not empty, the first process is removed from it and added to the runnable processes in the scheduler. If the semaphore is empty its excess signals count is incremented. > > Given these three statements it is easy to see how they work, how to use them for mutual exclusion, etc. > > > > signal > "Primitive. Send a signal through the receiver. If one or more processes > have been suspended trying to receive a signal, allow the first one to > proceed. If no process is waiting, remember the excess signal. Essential. > See Object documentation whatIsAPrimitive." > > <primitive: 85> > self primitiveFailed > > "self isEmpty > ifTrue: [excessSignals := excessSignals+1] > ifFalse: [Processor resume: self removeFirstLink]" > > > I wanted to know what is really happening when a semaphore is signalled. > Now resume: does not exist on Processor. > > I will look in the VM code. > > > S > > > > > > S. > > > > -- > _,,,^..^,,,_ > best, Eliot

Jan. 10, 2020

Re: [Pharo-dev] about signal

by Ben Coman

For greater visibility and comprehension, it might be useful to early in the manual define a utility method... Object>>crTracePriority self crTrace: '[', Processor activePriority printString, ']', self printString On Fri, 10 Jan 2020 at 13:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Thu, Jan 9, 2020 at 5:03 AM ducasse <stepharo(a)netcourrier.com> wrote: > >> Hi >> >> I wanted to explain >> >> | semaphore p1 p2 | >> semaphore := Semaphore new. >> p1 := [ semaphore wait. >> 'p1' crTrace ] fork. >> >> p2 := [semaphore signal. >> 'p2' crTrace ] fork. >> >> displays p2 and p1. >> but I would like explain clearly but it depends on the semantics of >> signal. >> >> >> - ==p1== is scheduled and its execution starts to wait on the semaphore, >> so it is removed from the run queue of the scheduler and added to the >> waiting list of the semaphore. >> - ==p2== is scheduled and it signals the semaphore. The semaphore takes >> the first waiting process (==p1==) and reschedule it by adding it to the >> end of the suspended lists. >> > > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 > will start to run until something else happens after the execution of p1 := > [...] fork. p2 := [...] fork. So for example, if there is Processor yield > then p1 can start to run. > > So you need to add code to your example to be able to determine what will > happen. The easiest thing would be to delay long enough that both can run. > 1 millisecond is more than enough. > This is a good point. It may be useful for the example to be expanded to... | semaphore p1 p2 | semaphore := Semaphore new. p1 := [ semaphore wait. 'Process 1' crTracePriority ] fork. p2 := [semaphore signal. 'Process 2' crTracePriority ] fork. 'Original process pre-yield' crTracePriority . 1 milliSeconds wait. 'Original process post-yield' crTracePriority . which would produce==> [40]'Original process pre-yield' [40]'Process 2' [40]'Process 1' [40]'Original process post-yield' with other examples producing... [40]'Original process pre-yield' [30]'Process 1' [20]'Process 2' [40]'Original process post-yield' [60]'Process 2' [50]'Process 1' [40]'Original process pre-yield' [40]'Original process post-yield' > > >> Now this sentence "The semaphore takes the first waiting process (==p1==) >> and reschedule it by adding it to the end of the suspended lists.â is super >> naive. Is the semaphore signalling scheduled? or not? >> > > I would say these three things, something like this: > > "A semaphore is a queue (implemented as a linked list) and an excess > signals count, which is a non-negative integer. On instance creation a new > semaphore is empty and has a zero excess signals count. A semaphore > created for mutual exclusion is empty and has an excess signals count of > one." > > "When a process waits on a semaphore, if the semaphore's excess signals > count is non-zero, then the excess signal count is decremented, and the > process proceeds. But if the semaphore has a zero excess signals count > then the process is unscheduled and added to the end of the semaphore, > after any other processes that are queued on the semaphore." > > "When a semaphore is signaled, if it is not empty, the first process is > removed from it and added to the runnable processes in the scheduler. If > the semaphore is empty its excess signals count is incremented. > > Given these three statements it is easy to see how they work, how to use > them for mutual exclusion, etc. > > >> >> signal >> "Primitive. Send a signal through the receiver. If one or more >> processes >> have been suspended trying to receive a signal, allow the first >> one to >> proceed. If no process is waiting, remember the excess signal. >> Essential. >> See Object documentation whatIsAPrimitive." >> >> <primitive: 85> >> self primitiveFailed >> >> "self isEmpty >> ifTrue: [excessSignals := excessSignals+1] >> ifFalse: [Processor resume: self removeFirstLink]" >> >> >> I wanted to know what is really happening when a semaphore is signalled. >> Now resume: does not exist on Processor. >> >> I will look in the VM code. >> >> For quick reference, here is some relevant VM code (the StackInterpreter code is a little simpler...) https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/pharo/headless/small… StackInterpreter class >> initializePrimitiveTable [ ... "Control Primitives (80-89)" (85 primitiveSignal) (86 primitiveWait) ... ] https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/pharo/headless/small… InterpreterPrimitives >> primitiveWait [ | sema excessSignals activeProc | sema := self stackTop. "rcvr" excessSignals := self fetchInteger: ExcessSignalsIndex ofObject: sema. excessSignals > 0 ifTrue: [self storeInteger: ExcessSignalsIndex ofObject: sema withValue: excessSignals - 1] ifFalse: [activeProc := self activeProcess. self addLastLink: activeProc toList: sema. self transferTo: self wakeHighestPriority] ] https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/pharo/headless/small… InterpreterPrimitives >> primitiveSignal [ "Synchronously signal the semaphore. This may change the active process as a result." self synchronousSignal: self stackTop ] https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/pharo/headless/small… StackInterpreter >> synchronousSignal: aSemaphore [ "Signal the given semaphore from within the interpreter. Answer if the current process was preempted." | excessSignals | <inline: false> (self isEmptyList: aSemaphore) ifTrue: ["no process is waiting on this semaphore" excessSignals := self fetchInteger: ExcessSignalsIndex ofObject: aSemaphore. self storeInteger: ExcessSignalsIndex ofObject: aSemaphore withValue: excessSignals + 1. ^false]. objectMemory ensureSemaphoreUnforwardedThroughContext: aSemaphore. ^self resume: (self removeFirstLinkOfList: aSemaphore) preemptedYieldingIf: preemptionYields ] cheers -ben

Jan. 10, 2020

Re: [Pharo-dev] about signal

by Nicolas Cellier

For example, whether a Semaphore would queue waiting process by order of registration (thru a linked list for example) or by order of priority (thru a Heap for example), would completely change its behavior. So isn't that kind of implementation detail SUPER important, especially when hidden in VM? Also, describing HOW it works is very often used as a mean to explain (and make understand) a higher level feature. IMO, understanding a feature from one implementation is as useful as understanding a feature by examples of usage. Even when implementation is plain Smalltalk, it's already an added value to give main guidelines to help reading code (see this particular class or message for understanding the core...), so when it's in VM... Le ven. 10 janv. 2020 Ã 12:59, Danil Osipchuk <danil.osipchuk(a)gmail.com> a Ã©crit : > I didn't claim expertise on the subject (although I use semaphores > extensively), nor its simplicity, nor that the implementation description > should be the only guide on its usage (hence 'to add..., how it works' > wording) > Said that, to me it is the case, when a clear description of what is going > on aids a lot. Instead of trying to define some rules and scenarios > abstractly - to help a user to reason about the system behavior (isn't Stef > was willing to look into VM code for this reason?). > > To me both scenarios of Stef could be explained that in first case the > 'signal' process is not getting preempted by the 'wait' process of the same > priority, while in second the preemption happens upon return from primitive > (hopefully my memory serves me well and my understanding is correct). > > A tangent note on comments in general -- I've noticed more than once, that > people tend to produce far clearer descriptions in exchanges like this -- > when discussing matter with others. > When a person is in documentation/comment writing mode he/she is sort of > tenses up in a formal state and often produces something not very helpful. > Current class comment of Semaphore is a perfect example, if I were not > familiar with the concept from other sources, I would not be able to make > any sense of it. So, I would suggest to use opportunities like this to > improve comments/docs when a bit of knowledge shows up in a discussion. > > > > regards, > Danil > > Ð¿Ñ, 10 ÑÐ½Ð². 2020 Ð³. Ð² 13:09, Sven Van Caekenberghe <sven(a)stfx.eu>: > >> Actually, it is just a, albeit concise, description of how Semaphores are >> implemented. >> >> It does not help much in understanding them, in learning how they >> can/should be used, for what purposes and how code behaves. >> >> Understanding of Process, priorities and Scheduling are also needed for a >> more complete understanding. >> >> This is not a simple subject. >> >> Read https://en.wikipedia.org/wiki/Semaphore_(programming) and see how >> well you understand the subject. >> >> In short, it does not answer Stef's concrete question(s). >> >> > On 10 Jan 2020, at 06:30, Danil Osipchuk <danil.osipchuk(a)gmail.com> >> wrote: >> > >> > Maybe to add this into the class comment, this is the most concise and >> clear description of how it works i've ever seen >> > >> > Ð¿Ñ, 10 ÑÐ½Ð². 2020 Ð³., 8:13 Eliot Miranda <eliot.miranda(a)gmail.com>: >> > >> > >> > On Thu, Jan 9, 2020 at 5:03 AM ducasse <stepharo(a)netcourrier.com> >> wrote: >> > Hi >> > >> > I wanted to explain >> > >> > | semaphore p1 p2 | >> > semaphore := Semaphore new. >> > p1 := [ semaphore wait. >> > 'p1' crTrace ] fork. >> > >> > p2 := [semaphore signal. >> > 'p2' crTrace ] fork. >> > >> > displays p2 and p1. >> > but I would like explain clearly but it depends on the semantics of >> signal. >> > >> > >> > - ==p1== is scheduled and its execution starts to wait on the >> semaphore, so it is removed from the run queue of the scheduler and added >> to the waiting list of the semaphore. >> > - ==p2== is scheduled and it signals the semaphore. The semaphore takes >> the first waiting process (==p1==) and reschedule it by adding it to the >> end of the suspended lists. >> > >> > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 >> will start to run until something else happens after the execution of p1 := >> [...] fork. p2 := [...] fork. So for example, if there is Processor yield >> then p1 can start to run. >> > >> > So you need to add code to your example to be able to determine what >> will happen. The easiest thing would be to delay long enough that both can >> run. 1 millisecond is more than enough. >> > >> > Now this sentence "The semaphore takes the first waiting process >> (==p1==) and reschedule it by adding it to the end of the suspended lists.â >> is super naive. Is the semaphore signalling scheduled? or not? >> > >> > I would say these three things, something like this: >> > >> > "A semaphore is a queue (implemented as a linked list) and an excess >> signals count, which is a non-negative integer. On instance creation a new >> semaphore is empty and has a zero excess signals count. A semaphore >> created for mutual exclusion is empty and has an excess signals count of >> one." >> > >> > "When a process waits on a semaphore, if the semaphore's excess signals >> count is non-zero, then the excess signal count is decremented, and the >> process proceeds. But if the semaphore has a zero excess signals count >> then the process is unscheduled and added to the end of the semaphore, >> after any other processes that are queued on the semaphore." >> > >> > "When a semaphore is signaled, if it is not empty, the first process is >> removed from it and added to the runnable processes in the scheduler. If >> the semaphore is empty its excess signals count is incremented. >> > >> > Given these three statements it is easy to see how they work, how to >> use them for mutual exclusion, etc. >> > >> > >> > >> > signal >> > "Primitive. Send a signal through the receiver. If one or more >> processes >> > have been suspended trying to receive a signal, allow the first >> one to >> > proceed. If no process is waiting, remember the excess signal. >> Essential. >> > See Object documentation whatIsAPrimitive." >> > >> > <primitive: 85> >> > self primitiveFailed >> > >> > "self isEmpty >> > ifTrue: [excessSignals := excessSignals+1] >> > ifFalse: [Processor resume: self removeFirstLink]" >> > >> > >> > I wanted to know what is really happening when a semaphore is >> signalled. >> > Now resume: does not exist on Processor. >> > >> > I will look in the VM code. >> > >> > >> > S >> > >> > >> > >> > >> > >> > S. >> > >> > >> > >> > -- >> > _,,,^..^,,,_ >> > best, Eliot >> >> >>

Jan. 10, 2020

TechTalks: Dates + Call

by Marcus Denker

Hi, Here are dates for the Pharo TechTalks first half of 2020: January 23: https://association.pharo.org/event-3697009 Thursday 20 https://association.pharo.org/event-3697011 March 19 https://association.pharo.org/event-3697012 April 23 https://association.pharo.org/event-3697013 May 28 https://association.pharo.org/event-3697016 June 18 https://association.pharo.org/event-3697017 We need topics! If you want to take over one of these talks to show your project (or something that you find interesting) â> send me a mail. The date/time can be changed as needed, too. Archive of past techtalks: https://pharo.org/TechTalk

Jan. 10, 2020

[Pharo 9.0] Build #4: Improving metalink printing and visualization in Calypso

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #4 was: SUCCESS. The Pull Request #5456 was integrated: "Improving metalink printing and visualization in Calypso" Pull request url: https://github.com/pharo-project/pharo/pull/5456 Issue Url: https://github.com/pharo-project/pharo/issues/Metalink Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 10, 2020

Re: [Pharo-dev] Little challenge

by ducasse

Hello alejandro Thanks for the reminder. I will have a look. S > On 10 Jan 2020, at 12:26, Alejandro Infante <alejandroinfante91(a)gmail.com> wrote: > > The profiler of my master thesis does this (and a lot more). It instruments new on all classes in a package + some other core things like String, Color, Rectangle and Collections and check if some of them have equivalent state and are immutable. If they are the profiler allows you to group the instances by the context where you allocated them (a simple stack trace, nothing fancy). > > http://repositorio.uchile.cl/bitstream/handle/2250/147381/Discovering-memor… <http://repositorio.uchile.cl/bitstream/handle/2250/147381/Discovering-memor…> > > It doesnât have a cool ui, but it works :) > > Alejandro > >> On Jan 9, 2020, at 7:17 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> >> Another requirement for caching and sharing instances is that the object is a true read only value object. >> >>> On 9 Jan 2020, at 22:45, Esteban Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >>> >>> Well... the theme having these colors in a table of some sort, even >>> keyed by a role name (very much like windows), isn't like a lot of >>> work. >>> >>> Of course, "premature optimization is the root of all evil". But given >>> that such "careless" behavior has been around for a while, maybe it is >>> not premature any longer. :) >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >>> On Thu, Jan 9, 2020 at 5:14 PM Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >>>> >>>> ducasse wrote >>>>> it looks like a real plague. >>>> >>>> What is the real effect on performance? There is a cost to the complexity of >>>> e.g. caching too, no? >>>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> >>>> >>> >> >> >

Jan. 10, 2020

Re: [Pharo-dev] about signal

by Danil Osipchuk

I didn't claim expertise on the subject (although I use semaphores extensively), nor its simplicity, nor that the implementation description should be the only guide on its usage (hence 'to add..., how it works' wording) Said that, to me it is the case, when a clear description of what is going on aids a lot. Instead of trying to define some rules and scenarios abstractly - to help a user to reason about the system behavior (isn't Stef was willing to look into VM code for this reason?). To me both scenarios of Stef could be explained that in first case the 'signal' process is not getting preempted by the 'wait' process of the same priority, while in second the preemption happens upon return from primitive (hopefully my memory serves me well and my understanding is correct). A tangent note on comments in general -- I've noticed more than once, that people tend to produce far clearer descriptions in exchanges like this -- when discussing matter with others. When a person is in documentation/comment writing mode he/she is sort of tenses up in a formal state and often produces something not very helpful. Current class comment of Semaphore is a perfect example, if I were not familiar with the concept from other sources, I would not be able to make any sense of it. So, I would suggest to use opportunities like this to improve comments/docs when a bit of knowledge shows up in a discussion. regards, Danil Ð¿Ñ, 10 ÑÐ½Ð². 2020 Ð³. Ð² 13:09, Sven Van Caekenberghe <sven(a)stfx.eu>: > Actually, it is just a, albeit concise, description of how Semaphores are > implemented. > > It does not help much in understanding them, in learning how they > can/should be used, for what purposes and how code behaves. > > Understanding of Process, priorities and Scheduling are also needed for a > more complete understanding. > > This is not a simple subject. > > Read https://en.wikipedia.org/wiki/Semaphore_(programming) and see how > well you understand the subject. > > In short, it does not answer Stef's concrete question(s). > > > On 10 Jan 2020, at 06:30, Danil Osipchuk <danil.osipchuk(a)gmail.com> > wrote: > > > > Maybe to add this into the class comment, this is the most concise and > clear description of how it works i've ever seen > > > > Ð¿Ñ, 10 ÑÐ½Ð². 2020 Ð³., 8:13 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Thu, Jan 9, 2020 at 5:03 AM ducasse <stepharo(a)netcourrier.com> wrote: > > Hi > > > > I wanted to explain > > > > | semaphore p1 p2 | > > semaphore := Semaphore new. > > p1 := [ semaphore wait. > > 'p1' crTrace ] fork. > > > > p2 := [semaphore signal. > > 'p2' crTrace ] fork. > > > > displays p2 and p1. > > but I would like explain clearly but it depends on the semantics of > signal. > > > > > > - ==p1== is scheduled and its execution starts to wait on the semaphore, > so it is removed from the run queue of the scheduler and added to the > waiting list of the semaphore. > > - ==p2== is scheduled and it signals the semaphore. The semaphore takes > the first waiting process (==p1==) and reschedule it by adding it to the > end of the suspended lists. > > > > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 > will start to run until something else happens after the execution of p1 := > [...] fork. p2 := [...] fork. So for example, if there is Processor yield > then p1 can start to run. > > > > So you need to add code to your example to be able to determine what > will happen. The easiest thing would be to delay long enough that both can > run. 1 millisecond is more than enough. > > > > Now this sentence "The semaphore takes the first waiting process > (==p1==) and reschedule it by adding it to the end of the suspended lists.â > is super naive. Is the semaphore signalling scheduled? or not? > > > > I would say these three things, something like this: > > > > "A semaphore is a queue (implemented as a linked list) and an excess > signals count, which is a non-negative integer. On instance creation a new > semaphore is empty and has a zero excess signals count. A semaphore > created for mutual exclusion is empty and has an excess signals count of > one." > > > > "When a process waits on a semaphore, if the semaphore's excess signals > count is non-zero, then the excess signal count is decremented, and the > process proceeds. But if the semaphore has a zero excess signals count > then the process is unscheduled and added to the end of the semaphore, > after any other processes that are queued on the semaphore." > > > > "When a semaphore is signaled, if it is not empty, the first process is > removed from it and added to the runnable processes in the scheduler. If > the semaphore is empty its excess signals count is incremented. > > > > Given these three statements it is easy to see how they work, how to use > them for mutual exclusion, etc. > > > > > > > > signal > > "Primitive. Send a signal through the receiver. If one or more > processes > > have been suspended trying to receive a signal, allow the first > one to > > proceed. If no process is waiting, remember the excess signal. > Essential. > > See Object documentation whatIsAPrimitive." > > > > <primitive: 85> > > self primitiveFailed > > > > "self isEmpty > > ifTrue: [excessSignals := excessSignals+1] > > ifFalse: [Processor resume: self removeFirstLink]" > > > > > > I wanted to know what is really happening when a semaphore is signalled. > > Now resume: does not exist on Processor. > > > > I will look in the VM code. > > > > > > S > > > > > > > > > > > > S. > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > >

Jan. 10, 2020