Re: ReadWriteLock rather on map's each field than whole map?
- From: Hunter Gratzner <a24900@xxxxxxxxxxxxxx>
- Date: Sat, 29 Sep 2007 15:49:57 -0000
On Sep 29, 1:37 pm, easy <easy....@xxxxxxxxx> wrote:
I would like to apply
java.util.concurrent.locks.ReentrantReadWriteLock
on a HashMap(or ConcurrentHashMap)
Using ConcurrentHashMap and an additional lock doesn't make much
sense. ConcurrentHashMap allows for concurrent updates and reads,
with minimized locking.
If you need to protect multiple map operations in a row in order to
keep the map consistent, then ConcurrentHashMap is not what you need.
Then you need an additional lock and a normal HashMap. With HashMap
you are lucky. The API documentation guarantees that concurrent reads
are permitted. So a "multipe readers, single writer lock", like
ReentrantReadWriteLock is appropriate for this.
But I think you can get away with a ConcurrentHashMap.
Most examples on internet applies ReadWriteLock on whole map.
that is, every setter/write (whatever which "field") on map will block
other getter (read) operation or other setter on different field.
Yes, and that's how you do it, since HashMap can not stomach to be
updated in parallel from different threads. If you need something
different write your own implementation (good luck with that).
because I build a cache map for DB.
the map setter will occurs when read miss.
In the setter the object will be load from DB, and it may very time-
consumed.
That statement does not make sense. Why do you intend to write-lock
the map during the time you fetch the data from the DB?
Consider the following pseudo code:
ConcurrentHashMap cache = ... // thread safe
HashSet ongoingRequests = // not thread safe, need to lock
explicitly
read(key) {
if(value = cache.get(key)) {
return value
}
//
// To avoid loading the same key in
// parallel, keep a list of
// keys for which currently DB requests
// are done.
//
synchronize(ongoingRequests) {
if ongoingRequests.get(key) {
while(! value = cache.get(key) {
ongoingRequests.wait()
}
return value
} else {
// need to double-check
if(value = cache.get(key)) {
return value
}
ongoingRequests.add(key)
}
}
value = requestValueFromDb(key) // method needs to be thread safe
cache.add(key, value)
synchronize(ongoingRequests) {
ongoingRequests.remove(key)
ongoingRequests.notifyAll()
}
return value
Please note that you need to carefully check the above code if it is
indeed thread safe. I just did it on the fly (never a good idea when
dealing with threads), and didn't think much about it (a big sin when
doing threads).
does someone have idea?
Consider getting a good book about threading. Alternatively, and this
is a serious suggestion, don't use multi-threading in your
application.
.
- Follow-Ups:
- References:
- Prev by Date: Re: nullPointerException in abstract class
- Next by Date: Re: Convert from text string "Hello" to floating-point number issue
- Previous by thread: Re: ReadWriteLock rather on map's each field than whole map?
- Next by thread: Re: ReadWriteLock rather on map's each field than whole map?
- Index(es):
Relevant Pages
|
|
