On 11 Dec 2013, at 14:03, Sven Van Caekenberghe <[email protected]> wrote:
> > On 11 Dec 2013, at 13:42, Jan Vrany <[email protected]> wrote: > >> On 11/12/13 12:20, Sven Van Caekenberghe wrote: >>> Hi Jan, >>> >>> On 11 Dec 2013, at 12:49, Jan Vrany <[email protected]> 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. === Name: Neo-Caching-SvenVanCaekenberghe.15 Author: SvenVanCaekenberghe Time: 11 December 2013, 5:07:11.601995 pm UUID: 35273b73-8caf-4810-afc5-614d7c690580 Ancestors: Neo-Caching-SvenVanCaekenberghe.14 processed some feedback by Jan Vrany (Thx!): - renamed #useSemaphore to #beThreadSafe - use a Monitor instead of a Semaphore for mutual exclusion so that it can be re-entered safely - added #testFibonacci - added some clarifications to NeoTTLCache's class comment === > 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 >
