October 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Shared directories: The bug is quicker than the eye

by Schwab,Wilhelm K

Hello all, I'm not sure what to make of this one. I just spent a couple of hours trying to find the "leak" in an algorithm of mine. It was reading roughly 1200 records, claiming to have processed all of them, and yet writing only about 450 rows into an output text file. One clue should have been that the number of output rows was somewhat random; I did not fully appreciate that until I worked around the problme. I tried an explicit #flush - no help. I looked for logic errors and found none. The file was being written to a Windows hosted share mounted by CIFS (which I am learning to view with contempt) from Ubuntu 9.04. You can see where this is going: writing the file locally gave the expected result. Any ideas on how one might further isolate the problem? My trust in Windows is well known<g>; I have never liked shared directories; I _really_ do not like CIFS as compared (reliability wise) to SMBFS; the network between me and the server is in question too (long story). All of that said, file support in Squeak, and hence so far inherited by Pharo, is not the best code I have seen to date, so it is easy to suspect too. Can one argue that since it worked locally, Pharo is not the problem? The little bit that I know of cifs is not encouraging. It sounds as though things moved from an easily killed process into the kernel which shows an almost Windows-like unwillingness to shut down when it cannot see servers. I have found numerous reports of problems copying large files over cifs, and I have enountered them too. Bill

Oct. 23, 2009

Re: [Pharo-project] Thread-safe collections

by Schwab,Wilhelm K

Sig, One can always construct examples in which protecting the entire loop is the better option. That's not the scenario of interest. Just as shared queues are useful, shared sets and dictionaries have value for sporadic access scenarios. Doing it your way, everyone writes their own incompletely protected (read buggy/dangerous) ad-hoc implementations of these common collections. I favor having solid implementations that are complete and as correct as we can get them, leaving people to optimize as you suggest when it makes sense to do so. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, October 22, 2009 5:23 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections 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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2009

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