>>>
>>> >> >> Thanks, Levente for giving a feedback. >> Please, feel free to shape my classes in more complete from (such as >> proper naming), >> to make them ready for inclusion in both Squeak's and Pharo cores. >> I propose the following names: >> AtomicQueue (base class) -> AtomicCollection >> FIFOQueue -> AtomicQueue >> LIFOQueue -> AtomicStack >> If you, or anyone else having better suggestions, speak now :) > > > Sounds like good names. > > >> In any case, i'm am open to discuss further details and possible >> caveats of using new classes >> to anyone interested in using them. >> >> P.S. As a side note, i now can explain (to myself at first place), why >> i intuitively choosed to used atomic swap >> instead of CAS. >> Because it fits better fits with smalltalk language semantics: >> >> A swap operation in smalltalk implemented as two assignments: >> x := y. y := z. >> An assignments is basic operation, which have nothing to do with >> late-bound nature of language. >> Unless we going to introduce a meta-object protocol(s), which could >> turn a simple assignment >> into some message sends under the hood, it will remain a basic, >> early-bound operation. >> And even if we do, it is highly unlikely, that even then we will throw >> away the old, >> simple assignment, which identifies an assignment source & target at >> compile time. >> >> In contrast, a CAS operation , if written in smalltalk looks like: >> >> (a == b ) ifTrue: [ a := c ] >> >> so, it having two message sends (#== , #ifTrue:), and from strict, >> pure language perspective, >> this using a late-bound semantics (a message sends), >> and as any message send, the message result and behavior cannot be >> predicted at compile time >> and therefore its wrong to assume that such statement could be an >> atomic operation. >> >> Unless, of course, we introduce a new language syntax which will >> denote a CAS operation explicitly. >> >>> >>> Levente >>> >>> >>> snip >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
I don't know if it's better (or even as good), but when the dust settles, it would be nice to have something _called_ SharedQueue that does what's expected of it and delegates to the improved classes. Another option would be to go through a deprecation period with SharedQueue.
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]] Sent: Monday, October 18, 2010 9:26 AM To: Pharo Development Subject: [Pharo-project] Fwd: [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale) >>> >>> >> >> Thanks, Levente for giving a feedback. >> Please, feel free to shape my classes in more complete from (such as >> proper naming), >> to make them ready for inclusion in both Squeak's and Pharo cores. >> I propose the following names: >> AtomicQueue (base class) -> AtomicCollection >> FIFOQueue -> AtomicQueue >> LIFOQueue -> AtomicStack >> If you, or anyone else having better suggestions, speak now :) > > > Sounds like good names. > > >> In any case, i'm am open to discuss further details and possible >> caveats of using new classes >> to anyone interested in using them. >> >> P.S. As a side note, i now can explain (to myself at first place), why >> i intuitively choosed to used atomic swap >> instead of CAS. >> Because it fits better fits with smalltalk language semantics: >> >> A swap operation in smalltalk implemented as two assignments: >> x := y. y := z. >> An assignments is basic operation, which have nothing to do with >> late-bound nature of language. >> Unless we going to introduce a meta-object protocol(s), which could >> turn a simple assignment >> into some message sends under the hood, it will remain a basic, >> early-bound operation. >> And even if we do, it is highly unlikely, that even then we will throw >> away the old, >> simple assignment, which identifies an assignment source & target at >> compile time. >> >> In contrast, a CAS operation , if written in smalltalk looks like: >> >> (a == b ) ifTrue: [ a := c ] >> >> so, it having two message sends (#== , #ifTrue:), and from strict, >> pure language perspective, >> this using a late-bound semantics (a message sends), >> and as any message send, the message result and behavior cannot be >> predicted at compile time >> and therefore its wrong to assume that such statement could be an >> atomic operation. >> >> Unless, of course, we introduce a new language syntax which will >> denote a CAS operation explicitly. >> >>> >>> Levente >>> >>> >>> snip >>> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |