On 24/03/14 18:20, Alexandre Bergel wrote:
My current understanding about thread is that there is a scheduling that may occurs
each time we enter the VM (e.g., primitive call, instantiating an object, throwing
an exception). So, the code "anOrderedCollection add: 42” will _never_ suffer
from concurrent call because adding 42 to a collection does not enter the VM. Does
this make sense?
I don't think so. AFAIK interrupts are checked on message sends and on
backward jumps (because of inlined loops just like in your example).
So context switch may happen on each send...
Ah yes!! I missed this case.
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?
Not really sure, since #signal and #wait are primitives,
but simple benchmark should do it :-)
However, you may want to use recursion lock (sometimes called
monitor - in Pharo class Monitor) which allows for recursion.
Otherwise you may get a nice deadlock if your code recurs.
Cost of recursion lock could be reduced to couple
machine instructions (if there's no contention), if done
properly. The implementation of Monitor in Pharo seems to be
way, way more costly than few instructions.
Jan
