>> Any idea what is the cost of using a semaphore? Inserting the expression 
>> "anOrderedCollection add: 42” in a semaphore surely make the expression 
>> slower. Any idea how much slower?
> 
> Can you elaborate a little on the problem.

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. 

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:

> Your granularity does not seem to be of the right level.
> Covering a single #add: operations is most probably rather fine grained, and 
> might not give you the guarantees you would expect.
> What exactly do you want to achieve?
> How many Smalltalk processes are interacting with that collection? How many 
> consumer/producer do you have?

Basically, all the processes may access my global polls by inserting or 
removing elements. 

> And well, on the standard priority, you normally got cooperative scheduling 
> anyway. So, it depends on what you are doing whether there is a real issue.
> And if you don’t want to use a semaphore, there are also other mechanism. I 
> think, there should be something like ‘execute uninterruptible’ for a block. 
> Think that raises the priority of the processes to the highest level for the 
> execution of the block, if I remember correctly.

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.

Alexandre


> 
> 
> Best regards
> Stefan
> 
> -- 
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
> 
> 
> 
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




Reply via email to