Here is the better documentation I found online about it when I learnt it: http://wiki.squeak.org/squeak/382
Afterwards... reading the vm and playing was the hard way to learn it... Then it seems there is an ongoing chapter in the topic https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/ConcurrencyBasics/ConcurrencyBasics.pier.html On Mon, Mar 24, 2014 at 10:54 PM, [email protected] <[email protected]>wrote: > On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel <[email protected] > > wrote: > >> >> I am working on a memory model for expandable collection in Pharo. >> Currently, OrderedCollection, Dictionary and other expandable collections >> use a internal array to store their data. My new collection library recycle >> these array instead of letting the garbage collector dispose them. I simply >> insert the arrays in an ordered collection when an array is not necessary >> anymore. And I remove one when I need one. >> > >> > Hm, is that really going to be worth the trouble? >> >> This technique reduces the consumption of about 15% of memory. >> >> >> At the end, #add: and #remove: are performed on these polls of >> arrays. I haven't been able to spot any problem regarding concurrency and I >> made no effort in preventing them. I have a simple global collection and >> each call site of "OrderedCollection new" can pick an element of my global >> collection. >> >> >> >> I have the impression that I simply need to guard the access to the >> global poll, which is basically guarding #add: #remove: and #includes: >> > >> > One of the AtomicCollections might be the right things for you? >> >> I will have a look at it. >> >> >> What is funny, is that I did not care at all about multi-threading and >> concurrency, and I have not spotted any problem so far. >> > >> > There isn't any 'multi-threading' like in Java, you got a much more >> control version: cooperative on the same priority, preemptive between >> priorities. >> > So, I am not surprised. And well, these operations are likely not to be >> problematic when they are racy, except when the underling data structure >> could get into an inconsistent state itself. The overall operations >> (adding/removing/searing) are racy on the application level anyway. >> > >> > However, much more interesting would be to know what kind of benefit do >> you see for such reuse? >> > And especially, with Spur around the corner, will it still pay off >> then? Or is it an application-specific optimization? >> >> I am exploring a new design of the collection library of Pharo. Not all >> the (academic) ideas will be worth porting into the mainstream of Pharo. >> But some of them yes. >> >> Thanks for all your help guys! You're great! >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > An interesting method I stumbled upon which may help in understanding how > these things do work. > > BlockClosure>>valueUnpreemptively > "Evaluate the receiver (block), without the possibility of preemption by > higher priority processes. Use this facility VERY sparingly!" > "Think about using Block>>valueUninterruptably first, and think about > using Semaphore>>critical: before that, and think about redesigning your > application even before that! > After you've done all that thinking, go right ahead and use it..." > | activeProcess oldPriority result semaphore | > activeProcess := Processor activeProcess. > oldPriority := activeProcess priority. > activeProcess priority: Processor highestPriority. > result := self ensure: [activeProcess priority: oldPriority]. > >
