# > Is there a standard idiom to do this, is there a way to have a finer
# > grained synchronization for the put ?
# The standard idiom is putIfAbsent.
# If putIfAbsent doesn't work for your situation, you'll need to adhere to
# a convention like "No one puts anything in the map without the foo
# lock", as you suggested. If that convention is uniformly adhered to,
# what you are doing is OK, if a little fragile.
# But if you're doing a lot of put'ing, this could be a serious
# scalability problem, because now every insertion must wait for a global,
# map-wide lock (the CHM implementation uses lock striping to allow writes
# to overlap), and performance may revert to something like that of
putIfAbsent is exactly what I need, thanks for pointing it out.
Could you elaborate on which situtation it wouldn't cater for ?
I had a stroll in the source for ConcurrentHashMap and understand the
locking works at the Segment level.
Would it be possible to implement an entry level locking provided we accept
a created entry
is never removed, only nulled.
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
[hidden email] wrote:
> putIfAbsent is exactly what I need, thanks for pointing it out.
> Could you elaborate on which situtation it wouldn't cater for ?
The common example is lazy initialization of a value if not present.
But this is usually better done by causing the Value object to
lazily initialize itself the first time it is accessed.
> I had a stroll in the source for ConcurrentHashMap and understand the
> locking works at the Segment level.
> Would it be possible to implement an entry level locking provided we accept
> a created entry
> is never removed, only nulled.
You might be able to copy-paste-hack a class that does this, but
there's no assurance that future releases of the java.util.concurrent
version will even use the same synchronization strategy, so beware!