[concurrency-interest] How to implement a self populating memoizer cache?

Nader Aeinehchi nader at aeinehchi.com
Wed Nov 3 08:31:11 EDT 2010

When I investigate the code in ExpiringComputingMap in MapMaker, I find 
blocks of code that seem to be compound operations (read-modify-write as 
stated on page 22 of JCiP book).

1. Please forgive me for my ignorance, but ExpiringComputingMap does not 
guarantee that a computable to be calculated only once for concurrent 
2. However, if we relax the requirement "only once" and allow a 
computable to be calculated few times, ExpiringComputingMap will work fine?

On 11/03/2010 01:18 PM, Dhanji R. Prasanna wrote:
> Take a look at the implementation of MapMaker from guava libraries. 
> That should give you some ideas too.
> Dhanji.
> On Wed, Nov 3, 2010 at 8:07 PM, Nader Aeinehchi <nader at aeinehchi.com 
> <mailto:nader at aeinehchi.com>> wrote:
>     Hello
>     How can a self populating cache be implemented?
>     Requirements:
>     1. the put(key,value) operation will be a memoizer (value =
>     computer(computable)) where computable==key.
>     2. how can a remove operation be implemented?
>     3. the cache will be thread safe
>     4. the cache will have a good performance for up to upper medium
>     contention (i.e. very high contention is not required)
>     5. preferrably a non-blocking algorithm
>     6. no need for timers,....
>     In advance, thank you very much.
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20101103/e890df7e/attachment-0001.html>

More information about the Concurrency-interest mailing list