Re: Followup to "Serious concurrency problems on fast systems"
Robert Klemme wrote:
the recent thread "Serious concurrency problems on fast systems"
inspired me to put together a small demo that shows how different ways
of concurrency control affect execution. The example shares a dummy
configuration with a single long value. Multiple threads access the
shared resource read only and depending on test scenario a single thread
updates it from time to time. Concurrency control is done in these way=
s:
1. Plain synchronized on a single shared resource.
2. Synchronized but with redundant storage and update via observer patter=
n.
3. Copy on write with an immutable object and an AtomicReference.
What about 'volatile'?
or
<http://java.sun.com/javase/6/docs/api/java/util/concurrent/atomic/
AtomicLong.html>
?
You can download it here
http://docs.google.com/leaf?id=0B7Q7WZzdIMlIMDI4ZDk0ZGItYzk1My00ZTc1L..=
..
Thank you for your contribution.
Aside from the semantics that you illustrate for updatable values,
nothing beats immutable (read-only, value fixed at initialization)
objects for safe and fast concurrency.
"But that's only for when you can get away with read-only values!" I
hear someone saying.
Yes, and one must always consider when one can get away with read-only
values. I've been on several projects where programmers used mutable
objects for concurrently-accessed objects with read-only usage. Often
they used lazy initialization, with broken double-checked locking yet!
for objects that never change value once initialized. Had they
considered the advantages of immutability, even constancy (e.g., for
read-only Strings), they would have prevented the concurrency and
performance issues their misguided implementations caused.
--
Lew