[concurrency-interest] Attempt at yet another mostly-concurrent result cache

Holger Hoffstätte holger at wizards.de
Tue Jan 9 08:38:25 EST 2007


Joe Bowbeer wrote:
> If you added a Lock to Batch then you might be able to improve
> efficiency by locking the newly constructed Batch before adding it to
> the cache.  Then you'd be sure no other thread could steal your new
> batch before you got a chance to use it.

After sleeping over it I just posted a similar (simpler) approach using a
wrapper, and I guess instead of using the wrapper for locking I could just
as well add a RWLock to the wrapper and use that for read/write lock
acquiry. Will think about it.

The loop also crossed my mind but then I had exactly this thought:

> Note that adding a loop raises the possibility of starvation (live-lock).
> 
> (What's the best way to plug that hole?)

..and I didn't really want to add that and backoff and *more* stuff yet.

The thing is that I could probably get by with a single big lock, but I'm
a bit annoyed that such a semingly trivial and obviously concurrent use
case is *so* hard to get right. There really should be a pattern language
for stepwise concurrentizing of sequential code, similar to Fowler's
refactorings.

Thanks for the comment!
Holger


More information about the Concurrency-interest mailing list