On 19 October 2010 02:06, Levente Uzonyi <[email protected]> wrote: > On Mon, 18 Oct 2010, Igor Stasenko wrote: > > snip > >> > > 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 :) > > > > I think these should be the names: > > FIFOQueue -> SharedQueue
this name already used by Kernel. So, unless my class will fully replace it, i see no way how i could use this name in separate package. Also, i must stress, that behavior of FIFOQueue only attempts to closely resemble the SharedQueue behavior. However, there is a situations (related to how scheduling works and use of #yield), where using them could lead to deadlocks. In this regard, an AtomicSharedQueue (a subclass of FIFOQueue) is much better analogy to current SharedQueue. As i noted in another mail, i see that we might also provide a separate wait-free interface. So we can guarantee, that if you using only wait-free interface, a queue can never be the cause of deadlock. > LIFOQueue -> SharedStack > > I don't know a really good name for AtomicQueue, maybe SharedList, > SharedCollection or SharedListStub. > > > Levente > > > > 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
