[concurrency-interest] Problem with using an unbounded map of Mutex lock objects

Tim Peierls tim at peierls.net
Sun Jun 4 08:39:20 EDT 2006


I mean that the underlying caching mechanism needs to be thread-safe and to
provide atomic put-if-absent and remove-with-given-value operations in order
to use the blocking get approach I sketched. ConcurrentHashMap has those
properties, but if you run into trouble implementing your Cache class on top
of it, you can still use the lock-striping approach used internally by CHM
to build your own ConcurrentMap-like mechanism.

I should mention that I have a vested interest in the performance and
scalability of ehcache, because I am one of your users (via Hibernate)! :-)

--tim

On 6/4/06, Greg Luck <gluck at gregluck.com> wrote:
>
> Tim
> Is your code example a complete solution? Do you mean that the
> lock-striping is an alternative to your implementation?
>
> In any case  I will run your solution over my mult-threaded torture tests
> this week.
>
> On 04/06/2006, at 2:43 AM, Tim Peierls wrote:
>
> And in case it wasn't clear, you will still want to pursue the lock
> striping approach that Brian described to get ConcurrentMap-like behavior.
>
> --tim
>
> On 6/3/06, Tim Peierls <tim at peierls.net> wrote:
> >
> > I believe the approach will scale very well. For ehcache, you have
> > serialization concerns that are not addressed in the code below, but this
> > should be independent of the blocking get issue.
> >
>
>
>
>
> Regards
>
>
> Greg Luck
>
> web: http://gregluck.com
> skype: gregrluckyahoo: gregrluck
> mobile: +61 408 061 622
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060604/2a4c3cfa/attachment-0001.html 


More information about the Concurrency-interest mailing list