15-Nov-2013 03:35, Charles Hixson пишет:
On 11/14/2013 01:36 PM, ilya-stromberg wrote:
On Thursday, 14 November 2013 at 21:31:52 UTC, Jacek Furmankiewicz wrote:
hashmap per thread is not an option. The cache may be a few GBs of
data, there is no way we can duplicate that data per thread.
Not to mention the start up time when we have to warm up the cache.
How often do you change the data? Probably, you should use `immutable`
variables.
Immutable variables are nice when they can be used. Often, however,
they can't.
I think that for the "concurrent hashmap" the best answer is probably to
run the map in a thread, with message passing access whether for read or
write.
Would be slow unless batched. At least in D message passing involves
locking/unlocking a queue of messages. Sending back and forth you get 2
lock-wait-unlock and correspondingly context switches.
And I wouldn't be surprised if that's how Java's concurrent
hashmap is implemented under the covers. (OTOH, I haven't ever debugged
such a setup. Someone who has may have a better answer.)
As stated in Oracle's documentation somewhere it's implemented with fine
grained locking (a lock per bucket of a hash map), some operations still
lock the whole map. Rehashing still locks the whole thing I bet.
--
Dmitry Olshansky
