[concurrency-interest] ConcurrentReferenceMap enhancement to 166 - Feedback Requested
Jason T. Greene
jason.greene at redhat.com
Thu Apr 17 10:32:54 EDT 2008
Dhanji R. Prasanna wrote:
> Hi Jason (Greene)
> This is cool =)
> I also prefer the enum as it is a tight contract.
> Btw, doesn't google-collections have a similar utility? > I notice that it
> uses a composition pattern with CHM, and that your version does not.
Yes, for others that are interested. Google has a similar table here
It uses a delegation approach which is more limiting:
- Can't do standard equality with weak/soft types
- Requires a separate application thread for stale entry cleanup
- Needs a lot of extra method dispatch
Doug and I have been talking with some of the folks at Google about
this. They have been after a standardized solution as well.
> Can I ask about the motivation for this? (I presume, without due
> that a similar lock-striping strategy to CHM is in use?)
The motivation is to maximize performance, and solve the above issues.
It's actually a derivative of the CHM code, so pretty much the same
performance aspects, with of course some small additional overhead for
tracking references. So, reads are non-blocking, writes are striped.
Each segment has it's own reference queue that is lazily purged when a
lock is acquired on that segment. There is also a purgeStaleEntries()
method that can be called from any thread should an application wish to
do this eagerly, although this triggers a lock acquisition on all
segments, one at a time.
Jason T. Greene
JBoss, a division of Red Hat
More information about the Concurrency-interest