- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Thread-safe collections

by Michael van der Gulik

On Fri, Oct 23, 2009 at 11:23 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > > Hello all, > > > > I just looked around for thread-safe collections, and found nothing that > looks like a shared dictionary. The squeak-dev archives contain the > obligatory newbie posts (wanting all collections to be thread safe) and the > expected replies, some of which are overly dismissive of the idea. > Something that protects things like #at:ifAbsentPut: and friends is > _really_ useful. Am I missing an existing implementation? > > > > Imo, there's only one shared collection which is useful - shared queue. :) > If you need more kinds of thread-safe collections, it probably > indicating that the concurrent code (or model) which you designed is > in pretty bad shape. > > Just compare two following snippets: > > 1 to: 100 do: [:i | collection threadSafeAt: i put: something]. > > and: > > semaphore critical: [ 1 to: 100 do: [:i | collection at: i put: something] > ]. > > What you think, which one is better? > > A thread-safe collection package could have non-blocking implementations of most methods. Writing an object reference into an array should be an atomic operation and I assume most collections use Arrays for their implementation. Gulik. -- http://gulik.pbwiki.com/

Oct. 22, 2009

Re: [Pharo-project] Thread-safe collections

by Andres Valloud

The Symbol table is another very useful collection that should be thread-safe. From my experience in VW, getting that to be both fast and thread-safe can be a bit tricky. For example, the debugger should not create symbols while debugging because you could be debugging the critical section of the symbol table internment... Igor Stasenko wrote: > 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > >> Hello all, >> >> I just looked around for thread-safe collections, and found nothing that looks like a shared dictionary. The squeak-dev archives contain the obligatory newbie posts (wanting all collections to be thread safe) and the expected replies, some of which are overly dismissive of the idea. Something that protects things like #at:ifAbsentPut: and friends is _really_ useful. Am I missing an existing implementation? >> >> > > Imo, there's only one shared collection which is useful - shared queue. :) > If you need more kinds of thread-safe collections, it probably > indicating that the concurrent code (or model) which you designed is > in pretty bad shape. > > Just compare two following snippets: > > 1 to: 100 do: [:i | collection threadSafeAt: i put: something]. > > and: > > semaphore critical: [ 1 to: 100 do: [:i | collection at: i put: something] ]. > > What you think, which one is better? > > > >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > >

Oct. 22, 2009

Re: [Pharo-project] Thread-safe collections

by Igor Stasenko

2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > I just looked around for thread-safe collections, and found nothing that looks like a shared dictionary. Â The squeak-dev archives contain the obligatory newbie posts (wanting all collections to be thread safe) and the expected replies, some of which are overly dismissive of the idea. Â Something that protects things like #at:ifAbsentPut: and friends is _really_ useful. Â Am I missing an existing implementation? > Imo, there's only one shared collection which is useful - shared queue. :) If you need more kinds of thread-safe collections, it probably indicating that the concurrent code (or model) which you designed is in pretty bad shape. Just compare two following snippets: 1 to: 100 do: [:i | collection threadSafeAt: i put: something]. and: semaphore critical: [ 1 to: 100 do: [:i | collection at: i put: something] ]. What you think, which one is better? > Bill > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 22, 2009

Re: [Pharo-project] Perfect hash [was: Re: HashTable vs Dictionary]

by Igor Stasenko

2009/10/22 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > My point would be that either: > > * the hashed storage is always of size 1000 (or greater), so if you > store a few objects in the hashed collection it wastes a lot of space; > > * the hashed storage changes size to match the objects stored in it, but > looking at f(x) mod p risks reintroducing the collisions you wanted to > avoid in the first place. > a different hash function picked if size of input set is changed. So, there is no chance to have storage of size 1000 , holding few elements (unless your implementation really suck :). That's why you can always be sure that your storage is good enough to store all of the elements and with minimal possible chances of collision. The only problem here, as i noted, that you have to rehash the storage each time you modifying the input set, because you changing the hash function which is 'optimal' for new input set. And that's why this approach is bad for sets which changing often. > So, to not waste space in this particular scenario, then either N should > be small or basically all N objects should be stored in the hashed > collection. Â If N is small, then why not set f(x) to produce values > between 1 and N, and then use an array? Â And if N is large and the > utilization of the hashed collection is close to 100% of N, then why not > also use an array in that case? Â In the end, really nice perfect hash > functions point the finger at alternatives that may obviate using hashed > collections. Â Of course, your mileage may vary... > perfect hash is just about that: find a function which having minimal , or no hash collisions and with storage size very close to the number of elements in input set. > Andres. > > > Martin McClure wrote: >> Andres Valloud wrote: >> >>> I thought I'd point out a subtle potential problem. Â Assume N = 1000, >>> f(x_j) = j-1, and so k = 1 because 0 <= f(x_j) < N because 0 < j <= >>> 1000. Â Now, store x_{7i} in a Set, for all i such that 1 <= 7i <= 1000. >>> Clearly, f(x) is a perfect hash function as defined above. Â However, if >>> the size of the table used by the set is a multiple of 7, performance >>> will be terrible. >>> >>> >> >> Huh? If your hash function produces integers between 0 and 999, your >> table size must be at least 1000, otherwise you store past the end of >> your table. >> >> Regards, >> >> -Martin >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 22, 2009

[Pharo-project] Thread-safe collections

by Schwab,Wilhelm K

Hello all, I just looked around for thread-safe collections, and found nothing that looks like a shared dictionary. The squeak-dev archives contain the obligatory newbie posts (wanting all collections to be thread safe) and the expected replies, some of which are overly dismissive of the idea. Something that protects things like #at:ifAbsentPut: and friends is _really_ useful. Am I missing an existing implementation? Bill

Oct. 22, 2009

Re: [Pharo-project] HashTable vs Dictionary

by Igor Stasenko

2009/10/22 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > The nice way of doing this would be to have a layer of indirection so > that the storage strategy decides how to use the hashed storage. > However, compared to the current Set/Dictionary implementation, that may > be a bit slower. Â It would not be a terrific idea to have multiple > subclasses of Set/Dictionary depending on the storage strategy, as that > would result in an explosion of classes. > Not necessary it should lead to explosion. We already having a storage in Set - array slot. So, its easy to imagine that this slot may change the class which implements the storage, while from outside you still seeing a Set. > John M McIntosh wrote: >> In the far past Visual Age would become the implementation logic for >> Sets depending >> on how big the set was, so for example with 10 elements it would be >> linear list. Â Of course >> it's been 14 years, perhaps I'm remembering it wrong. >> >> On 2009-10-22, at 6:46 AM, Lukas Renggli wrote: >> >> > -- Best regards, Igor Stasenko AKA sig.

Oct. 22, 2009

Re: [Pharo-project] the we site does not point to the rc1 image/

by Adrian Lienhard

right. thanks. Adrian On Oct 22, 2009, at 23:00 , Mariano Martinez Peck wrote: > You can do the same in http://www.pharo-project.org/home > > where it says "Current status: 1.0 beta" > > > On Thu, Oct 22, 2009 at 3:00 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > >> >> On Oct 22, 2009, at 18:14 , StÃ©phane Ducasse wrote: >> >>> ok I was wrong. >>> May be should change beta to Release Candidate in the heading. >> >> done >> ADrian >> >>> >>> stef >>> >>> On Oct 22, 2009, at 1:58 PM, Adrian Lienhard wrote: >>> >>>> which link do you mean? >>>> >>>> Adrian >>>> >>>> On Oct 22, 2009, at 12:37 , StÃ©phane Ducasse wrote: >>>> >>>>> can somebody fix it? >>>>> >>>>> Stef >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

Re: [Pharo-project] the we site does not point to the rc1 image/

by Mariano Martinez Peck

You can do the same in http://www.pharo-project.org/home where it says "Current status: 1.0 beta" On Thu, Oct 22, 2009 at 3:00 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > On Oct 22, 2009, at 18:14 , StÃ©phane Ducasse wrote: > > > ok I was wrong. > > May be should change beta to Release Candidate in the heading. > > done > ADrian > > > > > stef > > > > On Oct 22, 2009, at 1:58 PM, Adrian Lienhard wrote: > > > >> which link do you mean? > >> > >> Adrian > >> > >> On Oct 22, 2009, at 12:37 , StÃ©phane Ducasse wrote: > >> > >>> can somebody fix it? > >>> > >>> Stef > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2009

Re: [Pharo-project] New changes to Gofer

by Fernando olivero

Thanks for the advice! I'll adapt the AlienLoader to the work with Metacello and post it when its done. Fernando Il giorno Oct 22, 2009, alle ore 8:42 PM, Tudor Girba ha scritto: > If you want to take a look at the Metacello configuration of Moose, > you can find it in the ConfigurationOfMoose package. > > Cheers, > Doru > > > On 22 Oct 2009, at 20:40, StÃ©phane Ducasse wrote: > >> may be fernando you should have a look at Metacello >> because it is used gofer and it will be the way to go soon :) >> You can have a look at Glamour, Mondrian or MooseLoader as an >> example. >> >> Stef >> >> On Oct 22, 2009, at 8:34 PM, Fernando olivero wrote: >> >>> Hi, when loading Lumiere an deprecation warning comes up, seems that >>> the Flair configuration and gofer usage change significantly. >>> >>> Gofer Seems to have a much more expresive protocol now! Great! >>> >>> But could somebody provide examples on how to implement behavior >>> in a >>> loader for >>> >>> 1. loading the lastest versions of several packages. >>> 2. commit to squeaksource some pacakges >>> >>> Would be really helpfull to update Alien, AlienOpenGL, Lumiere >>> loaders. >>> >>> >>> Fernando >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

Re: [Pharo-project] Bug in OCompletion

by Mariano Martinez Peck

Yes! because it has also included a really nice improvement in the "UI" thanks to Michael Davids. On Thu, Oct 22, 2009 at 5:13 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Thanks indeed! > > I guess the fix made it in the latest dev image, because now it is a > pleasure to work with OCompletion. > > Cheers, > Doru > > > On 20 Oct 2009, at 02:18, Mariano Martinez Peck wrote: > > > Thanks to romain, he did a fix. I think it would be integrated in > > next Pharo dev. See details here: > > > > http://code.google.com/p/pharo/issues/detail?id=1236 > > > > cheers > > > > mariano > > > > On Sun, Oct 18, 2009 at 7:03 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com > > > wrote: > > This bug has been closed but I can still reproduce it in 10479. Can > > someone please test it and tell me if I am not > > > > the only one. > > > > Thanks > > > > mariano > > > > > > > > On Wed, Sep 23, 2009 at 4:29 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr > > > wrote: > > > > > > Begin forwarded message: > > > >> From: Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Date: September 23, 2009 8:20:40 PM CEDT > >> To: Pharo Development <pharo-project(a)lists.gforge.inria.fr> > >> Subject: [Pharo-project] Bug in OCompletion > >> Reply-To: Pharo-project(a)lists.gforge.inria.fr > >> > >> http://code.google.com/p/pharo/issues/detail?id=1236 > >> > >> Tested with OBSystemBrowserAdaptor in pharo1.0-10451-BETAdev09.09.3 > >> on Windows. > >> > >> To reproduce: > >> > >> 1) Open a System Browser > >> 2) Create a new class. When you do this, when you are changing > >> "#NameOfSubclass" to "#YourClass", after doing this press the down > >> arrow key > >> 3) An empty pop up will be brought and the keyboard won't respond. > >> To fix > >> this, you must press "Esc" key. > >> > >> > >> Best, > >> > >> Mariano > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, you will > end up with a messy haircut." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2009