John, No examples, just a growing surprise at the things that have been allowed to stand for many years, combined with respect for Object Arts. When in doubt, I assume they knew what they were doing, and making weaklings thread-safe seems reasonable, if not just plain necessary. My current concern is not over finalization specificially, but other weak collections.
You mention #forMutualExcusion. My understanding is that a semaphore so configured will allow a process to deadlock itself. We have Mutex, and it is probably a better choice?? Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of John M McIntosh Sent: Friday, October 23, 2009 8:25 PM To: [email protected] Subject: Re: [Pharo-project] Thread-safe collections Not sure what you are looking for a couple of years back I chased down a bug or two in the finalization logic See WeakArray>>FinalizationSemaphore and WeakRegistry accessLock := Semaphore forMutualExclusion. Both attempt to ensure finalization occurs in thread safe manners, this doesn't mean someone introduced something bad in the last 5 years or so. An example? On 2009-10-23, at 5:44 PM, Schwab,Wilhelm K wrote: > Stef, > > Dolphin's weak collections are typically (I suspect allways) thread > safe, which I have attributed to the constant struggle with > finalization - it seems natural (to me at least) for them to be > protected. Some quick browsing leads me to think that this is not > true in Pharo. Am I missing something, or do we also need some > thread-safe weaklings? > > Bill > > > > -----Original Message----- > From: [email protected] [mailto:pharo- > [email protected]] On Behalf Of Stéphane Ducasse > Sent: Friday, October 23, 2009 2:46 AM > To: [email protected] > Subject: Re: [Pharo-project] Thread-safe collections > > I would really like to see some packages getting implementing around > the idea of a couple of robust and well tested thread safe > collections. > > Stef > > On Oct 23, 2009, at 2:16 AM, Schwab,Wilhelm K wrote: > >> 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: [email protected] [mailto:pharo- >> [email protected]] On Behalf Of Igor Stasenko >> Sent: Thursday, October 22, 2009 5:23 PM >> To: [email protected] >> Subject: Re: [Pharo-project] Thread-safe collections >> >> 2009/10/23 Schwab,Wilhelm K <[email protected]>: >>> 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 >>> [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 >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <[email protected]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
