On 11 Dec 2013, at 13:42, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
On 11/12/13 12:20, Sven Van Caekenberghe wrote:
Hi Jan,
On 11 Dec 2013, at 12:49, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Hi,
By default, no concurrent access protection takes place, but optionally a semaphore for mutual exclusion can be used. This slows down access.
cache useSemaphore.
There was enough "awesomes" already :-) so now some critics :-)
I like constructive feedback !
Wouldn't it be better to rename #useSemaphore to #beThreadSafe or #beSynchronized.
Yes, specifying the goal/result is better than specifying the means. I think I will go for #beThreadSafe (although threads in Pharo are called Processes ;-). The last one reminds me of Java and we donât have a âsynchronisedâ concept in Pharo AFAIK.
Also I would use recursion lock (monitor, if you like) rather than plain mutex.
Iâve used both, they both work. But I must admit that in my mind the difference is not very clear. A monitor can be re-entered while a semaphore cannot,
That's exactly the difference, subtle but important :-)
but I doubt this is necessary here.
Imagine you need Fibonacci number and want to cache them for speed. How would one do that? Obvious solution would be:
fibCache := NeoCache ... fibCache factory: [:key | (fibCache at: key - 1) + (fibCache at: key - 1) ].
If I understood the code correctly `fibCache at: 10` would hang, right?
OK, you convinced me ! Thanks for the explanation. I will even make the fib example part of the unit tests. But I will probably change it to [ :key | key < 2 ifTrue: [ key ] ifFalse: [ (fibCache at: key - 1) + (fibCache at: key - 1) ] ] ;-)
Any other reasons to choose one over the other ? Speed ?
Speed-wise, it depends on implementation. The cost of recursion lock could be reduced to couple machine instructions in case there's no contention (which is usually the case).
Iâll measure it.
Actually, this would make an interesting use-case for NB...
Sven
Best, Jan