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