Re: Followup to "Serious concurrency problems on fast systems"

From:

Robert Klemme <shortcutter@googlemail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Sun, 04 Jul 2010 14:31:35 +0200

Message-ID:

<89bd9hFs3nU1@mid.individual.net>

On 04.07.2010 11:28, Christian wrote:

Am 02.07.2010 16:40, schrieb Robert Klemme:

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 ways:

1. Plain synchronized on a single shared resource.

2. Synchronized but with redundant storage and update via observer pattern.

3. Copy on write with an immutable object and an AtomicReference.

You can download it here

http://docs.google.com/leaf?id=0B7Q7WZzdIMlIMDI4ZDk0ZGItYzk1My00ZTc1LWJlYmQtNDYzNWNlNzA3YTJm&hl=en

You could also try the by Java provided (Reentrant)ReadWriteLock ...
it might (I am not sure there) be cheaper with lots of reads and few
writes than normal synchronization.

That's an excellent idea:

https://docs.google.com/leaf?id=0B7Q7WZzdIMlIZjAxZDg5YzYtNzE3YS00ZjAyLTgzMmQtMTExMmYwZjcwODAz&sort=name&layout=list&num=50

However, while it is faster than plain old synchronized on the global
resource, this confirms that centralized locking is an inferior approach
in highly concurrent systems. :-)

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/