Thread-safe collections
Locked
12
12
 
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Friday, October 23, 2009 2:46 AM To: [hidden email] 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: [hidden email] [mailto:pharo- > [hidden email]] On Behalf Of Igor Stasenko > Sent: Thursday, October 22, 2009 5:23 PM > To: [hidden email] > Subject: Re: [Pharo-project] Thread-safe collections > > 2009/10/23 Schwab,Wilhelm K <[hidden email]>: >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > 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 _______________________________________________ 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 |
|
|
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: [hidden email] [mailto:pharo- > [hidden email]] On Behalf Of Stéphane Ducasse > Sent: Friday, October 23, 2009 2:46 AM > To: [hidden email] > 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: [hidden email] [mailto:pharo- >> [hidden email]] On Behalf Of Igor Stasenko >> Sent: Thursday, October 22, 2009 5:23 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] Thread-safe collections >> >> 2009/10/23 Schwab,Wilhelm K <[hidden email]>: >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> 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 > > > _______________________________________________ > 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 -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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: [hidden email] [mailto:[hidden email]] On Behalf Of John M McIntosh Sent: Friday, October 23, 2009 8:25 PM To: [hidden email] 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: [hidden email] [mailto:pharo- > [hidden email]] On Behalf Of Stéphane Ducasse > Sent: Friday, October 23, 2009 2:46 AM > To: [hidden email] > 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: [hidden email] [mailto:pharo- >> [hidden email]] On Behalf Of Igor Stasenko >> Sent: Thursday, October 22, 2009 5:23 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] Thread-safe collections >> >> 2009/10/23 Schwab,Wilhelm K <[hidden email]>: >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> 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 > > > _______________________________________________ > 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 -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ 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 |
Re: Thread-safe collections
|
|
In reply to this post by Igor Stasenko
Igor Stasenko wrote:
> 2009/10/23 Schwab,Wilhelm K <[hidden email]>: >> 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. :) Yeah, sure. Where again do I store my Seaside sessions? Oh, it's no problem, because we use only one worker thread and process requests on after another. Geez, problem solved. Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
On Oct 23, 2009, at 3:31 PM, Schwab,Wilhelm K wrote: > Stef, > > With no disrespect to Sig's opinions, I'm glad to hear that. I very > quickly cobbled together a class called SharedLookupTable, and have > no problems making it (suitably debugged) available. > > Now it's time for me to kick your ass a little, to coin a phrase :) no problem > Monticello is pretty good at what it does, but I sense the things it > does not do interfering with good decision making. The class ended > up in my Dolphin compatibility package, in part because it belongs > there, though it really should be separate so I can easily release > it and people would be able to get it w/o having to accept other > ideas they might not want. But it went in the compatiblity package > so I would not have to mess around with another package. Saving > them is a pain; loading them into a new image is a pain. why? > Saving: the interface works well once understood, and the features > it offers should never go away. However, either by script or by > multiple selection, it would be nice to provide a comment to be > applied to everything to be saved "now" vs. having to be prompted > for it, then have the list scroll, then have to click away another > window. Do that 30 times and it starts to get old. this is strange because I thought that we fixed that pop up plague when saving slices Then you get all the comments you already typed in one of the button of the poped up window. Did you see it? > Loading: I spent a chunk of yesterday trying to build an RC1 image. > Doing so revealed that my script-loader for script-loader does not > validate package names. I had one build attempt come to a halt over > case-sensitivity; I do not mind that. What I mind is that the > particular case mix in question was more or less forced on me by a > typo of mine. If MC were better about offering choices when they > apply, I might not have typed it that way. > > I realize that Gofer is coming, and it might fix a lot of this. yes and also metacello which is coming along well > The ideas above are probably not new, but I list them just in case. > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:pharo- > [hidden email]] On Behalf Of Stéphane Ducasse > Sent: Friday, October 23, 2009 2:46 AM > To: [hidden email] > 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: [hidden email] [mailto:pharo- >> [hidden email]] On Behalf Of Igor Stasenko >> Sent: Thursday, October 22, 2009 5:23 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] Thread-safe collections >> >> 2009/10/23 Schwab,Wilhelm K <[hidden email]>: >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> 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 > > > _______________________________________________ > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Stef,
It sounds like I am indeed missing something in saving slices. I saw mention of it, but thought I read that it was not the preferred method and didn't dig further. Are you saying that I can make one big slice with all of my stuff and suddenly all becomes easy?? On the load side, I was having problems over name mis-matches that would not exist given a good packaging system. I could probably get around them now by reifying the names in my load script. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Sunday, October 25, 2009 2:59 PM To: [hidden email] Subject: Re: [Pharo-project] Thread-safe collections On Oct 23, 2009, at 3:31 PM, Schwab,Wilhelm K wrote: > Stef, > > With no disrespect to Sig's opinions, I'm glad to hear that. I very > quickly cobbled together a class called SharedLookupTable, and have no > problems making it (suitably debugged) available. > > Now it's time for me to kick your ass a little, to coin a phrase :) no problem > Monticello is pretty good at what it does, but I sense the things it > does not do interfering with good decision making. The class ended up > in my Dolphin compatibility package, in part because it belongs there, > though it really should be separate so I can easily release it and > people would be able to get it w/o having to accept other ideas they > might not want. But it went in the compatiblity package so I would > not have to mess around with another package. Saving them is a pain; > loading them into a new image is a pain. why? > Saving: the interface works well once understood, and the features it > offers should never go away. However, either by script or by multiple > selection, it would be nice to provide a comment to be applied to > everything to be saved "now" vs. having to be prompted for it, then > have the list scroll, then have to click away another window. Do that > 30 times and it starts to get old. this is strange because I thought that we fixed that pop up plague when saving slices Then you get all the comments you already typed in one of the button of the poped up window. Did you see it? > Loading: I spent a chunk of yesterday trying to build an RC1 image. > Doing so revealed that my script-loader for script-loader does not > validate package names. I had one build attempt come to a halt over > case-sensitivity; I do not mind that. What I mind is that the > particular case mix in question was more or less forced on me by a > typo of mine. If MC were better about offering choices when they > apply, I might not have typed it that way. > > I realize that Gofer is coming, and it might fix a lot of this. yes and also metacello which is coming along well > The ideas above are probably not new, but I list them just in case. > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:pharo- > [hidden email]] On Behalf Of Stéphane Ducasse > Sent: Friday, October 23, 2009 2:46 AM > To: [hidden email] > 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: [hidden email] [mailto:pharo- >> [hidden email]] On Behalf Of Igor Stasenko >> Sent: Thursday, October 22, 2009 5:23 PM >> To: [hidden email] >> Subject: Re: [Pharo-project] Thread-safe collections >> >> 2009/10/23 Schwab,Wilhelm K <[hidden email]>: >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> 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 > > > _______________________________________________ > 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 _______________________________________________ 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 |
|
|
In reply to this post by Philippe Marschall-2-3
Philippe, Stef,
That's fine for Seaside, but what about other users of weak collections? I think I have found the weakness (pun intended) in Squeak/Pharo: weaklings do only half of what they should do. They (correctly) do not prevent garbage collection of the objects they reference, but they apparently fail to clean up after these objects have been finalized. In Dolphin, the following returns an empty array: | map | map := WeakLookupTable new at:2 put:String new; yourself. MemoryManager current collectGarbage. map keys asArray. Pharo is content to answer nil from #at:put: but still keep the key: | map | map := WeakValueDictionary new at:2 put:String new; yourself. 5 timesRepeat:[ Smalltalk garbageCollect. ]. map keys asArray. Gary reported a lack of thread saftey in the weak collections almost two years ago. See Mantis #6955. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Philippe Marschall Sent: Sunday, October 25, 2009 9:44 AM To: [hidden email] Subject: Re: [Pharo-project] Thread-safe collections Igor Stasenko wrote: > 2009/10/23 Schwab,Wilhelm K <[hidden email]>: >> 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. :) Yeah, sure. Where again do I store my Seaside sessions? Oh, it's no problem, because we use only one worker thread and process requests on after another. Geez, problem solved. Cheers Philippe _______________________________________________ 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 |
|
|
2009/10/26 Schwab,Wilhelm K <[hidden email]>:
> Philippe, Stef, > > That's fine for Seaside, but what about other users of weak collections? I think I have found the weakness (pun intended) in Squeak/Pharo: weaklings do only half of what they should do. They (correctly) do not prevent garbage collection of the objects they reference, but they apparently fail to clean up after these objects have been finalized. > > In Dolphin, the following returns an empty array: > > | map | > map := WeakLookupTable new > at:2 put:String new; > yourself. > MemoryManager current collectGarbage. > map keys asArray. > > > Pharo is content to answer nil from #at:put: but still keep the key: > > | map | > map := WeakValueDictionary new > at:2 put:String new; > yourself. > 5 timesRepeat:[ Smalltalk garbageCollect. ]. > map keys asArray. > and why the key should go away? I think that this is an implementation nuance, but not bug or missing feature. No-one would expect from dictionary keys to automatically mutate depending on the state of the associated values. If you want such behavior, why not implement own WeakLookupTable ? > Gary reported a lack of thread saftey in the weak collections almost two years ago. See Mantis #6955. > > Bill > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Philippe Marschall > Sent: Sunday, October 25, 2009 9:44 AM > To: [hidden email] > Subject: Re: [Pharo-project] Thread-safe collections > > Igor Stasenko wrote: >> 2009/10/23 Schwab,Wilhelm K <[hidden email]>: >>> 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. :) > > Yeah, sure. Where again do I store my Seaside sessions? Oh, it's no problem, because we use only one worker thread and process requests on after another. Geez, problem solved. > > Cheers > Philippe > > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/10/27 Igor Stasenko <[hidden email]>:
> 2009/10/26 Schwab,Wilhelm K <[hidden email]>: >> Philippe, Stef, >> >> That's fine for Seaside, but what about other users of weak collections? I think I have found the weakness (pun intended) in Squeak/Pharo: weaklings do only half of what they should do. They (correctly) do not prevent garbage collection of the objects they reference, but they apparently fail to clean up after these objects have been finalized. >> >> In Dolphin, the following returns an empty array: >> >> | map | >> map := WeakLookupTable new >> at:2 put:String new; >> yourself. >> MemoryManager current collectGarbage. >> map keys asArray. >> >> >> Pharo is content to answer nil from #at:put: but still keep the key: >> >> | map | >> map := WeakValueDictionary new >> at:2 put:String new; >> yourself. >> 5 timesRepeat:[ Smalltalk garbageCollect. ]. >> map keys asArray. >> > > and why the key should go away? > I think that this is an implementation nuance, but not bug or missing feature. > No-one would expect from dictionary keys to automatically mutate > depending on the state of the associated values. > If you want such behavior, why not implement own WeakLookupTable ? > suppose, one may want to know, what values became garbage, to do additional _custom_ processing. While its currently possible using WeakValueDictionary , it will be problematic using WeakLookupTable , because you wont know what values are gone. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
On Oct 25, 2009, at 10:15 PM, Schwab,Wilhelm K wrote: > Stef, > > It sounds like I am indeed missing something in saving slices. I > saw mention of it, but thought I read that it was not the preferred > method and didn't dig further. Are you saying that I can make one > big slice with all of my stuff and suddenly all becomes easy?? if you have a package and some dependents when you will save a comments will be propagated to all the dependents no need to repeat that. > On the load side, I was having problems over name mis-matches that > would not exist given a good packaging system. I could probably get > around them now by reifying the names in my load script. I suggest that you start also to look at metacello because dale is managing glass with it and doru moose/mondrian.... in the future we want to manage the release with it. Stef > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:pharo- > [hidden email]] On Behalf Of Stéphane Ducasse > Sent: Sunday, October 25, 2009 2:59 PM > To: [hidden email] > Subject: Re: [Pharo-project] Thread-safe collections > > > On Oct 23, 2009, at 3:31 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> With no disrespect to Sig's opinions, I'm glad to hear that. I very >> quickly cobbled together a class called SharedLookupTable, and have >> no >> problems making it (suitably debugged) available. >> >> Now it's time for me to kick your ass a little, to coin a phrase :) > > no problem > >> Monticello is pretty good at what it does, but I sense the things it >> does not do interfering with good decision making. The class ended >> up >> in my Dolphin compatibility package, in part because it belongs >> there, >> though it really should be separate so I can easily release it and >> people would be able to get it w/o having to accept other ideas they >> might not want. But it went in the compatiblity package so I would >> not have to mess around with another package. Saving them is a pain; >> loading them into a new image is a pain. > > why? > >> Saving: the interface works well once understood, and the features it >> offers should never go away. However, either by script or by >> multiple >> selection, it would be nice to provide a comment to be applied to >> everything to be saved "now" vs. having to be prompted for it, then >> have the list scroll, then have to click away another window. Do >> that >> 30 times and it starts to get old. > > this is strange because I thought that we fixed that pop up plague > when saving slices Then you get all the comments you already typed > in one of the button of the poped up window. Did you see it? > > >> Loading: I spent a chunk of yesterday trying to build an RC1 image. >> Doing so revealed that my script-loader for script-loader does not >> validate package names. I had one build attempt come to a halt over >> case-sensitivity; I do not mind that. What I mind is that the >> particular case mix in question was more or less forced on me by a >> typo of mine. If MC were better about offering choices when they >> apply, I might not have typed it that way. >> >> I realize that Gofer is coming, and it might fix a lot of this. > > yes > and also metacello which is coming along well > >> The ideas above are probably not new, but I list them just in case. >> >> Bill >> >> >> >> -----Original Message----- >> From: [hidden email] [mailto:pharo- >> [hidden email]] On Behalf Of Stéphane Ducasse >> Sent: Friday, October 23, 2009 2:46 AM >> To: [hidden email] >> 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: [hidden email] [mailto:pharo- >>> [hidden email]] On Behalf Of Igor Stasenko >>> Sent: Thursday, October 22, 2009 5:23 PM >>> To: [hidden email] >>> Subject: Re: [Pharo-project] Thread-safe collections >>> >>> 2009/10/23 Schwab,Wilhelm K <[hidden email]>: >>>> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Igor Stasenko
On 2009-10-26, at 10:37 PM, Igor Stasenko wrote: > and why the key should go away? > I think that this is an implementation nuance, but not bug or > missing feature. > No-one would expect from dictionary keys to automatically mutate > depending on the state of the associated values. > If you want such behavior, why not implement own WeakLookupTable ? > Ok, well (a) I don't think any of the set or dictionary logic is particularly written with thread safety in mind. No doubt a Mutex is needed to protect the integrity of the data. Someone can decide which version of Pharo should a fix for 0006955 (b) Although as Igor mentioned the fact the key goes away is a implementation detail, this in fact is useful. The situation you run into is storing entities in a weak value dictionary where the values do disappear however if you store a million entries then you end up with a million keys, so who is responsible for the cleanup? -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
John,
I'm not sure whether we agree or disagree on individual points, but that's ok. I will invoke Sig in the case of 10^6 entries - something tells me one would end up with a customized implementation long before a weak collection became that large. However, I think automatic cleanup is important to keep a long-lived map from getting that large. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of John M McIntosh Sent: Tuesday, October 27, 2009 12:27 PM To: [hidden email] Subject: Re: [Pharo-project] Thread-safe collections On 2009-10-26, at 10:37 PM, Igor Stasenko wrote: > and why the key should go away? > I think that this is an implementation nuance, but not bug or missing > feature. > No-one would expect from dictionary keys to automatically mutate > depending on the state of the associated values. > If you want such behavior, why not implement own WeakLookupTable ? > Ok, well (a) I don't think any of the set or dictionary logic is particularly written with thread safety in mind. No doubt a Mutex is needed to protect the integrity of the data. Someone can decide which version of Pharo should a fix for 0006955 (b) Although as Igor mentioned the fact the key goes away is a implementation detail, this in fact is useful. The situation you run into is storing entities in a weak value dictionary where the values do disappear however if you store a million entries then you end up with a million keys, so who is responsible for the cleanup? -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ 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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |