[concurrency-interest] Attempt at yet another mostly-concurrent result cache
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
Thanks for the comment!
More information about the Concurrency-interest