concurrency

[Peter Ashford]

Hi All,

I've heard that the concurrency features in 1.5 are more efficient than
using synchronized(). Has anyone done any benchmarks on this?

I've got a class that is accessed from two threads, I was using
synchronized(my_private_lock_object) to prevent out-of-synch access to
crucial data, and I changed that to Lock.lock() - I'm wondering if it
makes any (even if minimal) speed difference?

Does anyone know of any really good, in depth articles about the new
primitives?

TIA

Peter.

 

[xarax]

Hi All,

I've heard that the concurrency features in 1.5 are more efficient than
using synchronized(). Has anyone done any benchmarks on this?

I've got a class that is accessed from two threads, I was using
synchronized(my_private_lock_object) to prevent out-of-synch access to
crucial data, and I changed that to Lock.lock() - I'm wondering if it
makes any (even if minimal) speed difference?

Does anyone know of any really good, in depth articles about the new
primitives?

The concurrency classes and interfaces support
the notion of read/write versus read/only. If
a thread is performing a read-only access of
a resource, then it can obtain the read-only
lock so that multiple threads can read the
resource. If a thread intends to change the
resource, then the read-write lock is obtained,
which blocks until no other threads have either
kind of lock.

With proper design and usage of read-only versus
read-write, the application can improve throughput,
because the alternative of using synchronized
blocks won't allow multiple read-only threads to
proceed concurrently.

Note that obtaining, testing, and releasing a
lock requires a synchronized block (along with
some wait/notify interaction), but those code
paths are very short.

In summary, if your application can benefit
from concurrent read-only versus single-threaded
read-write locking, then give it a try.

 

[Chris Uppal]

In summary, if your application can benefit
from concurrent read-only versus single-threaded
read-write locking, then give it a try.

[I'm not disagreeing with you here, just extending your point]

Note that the new stuff does not introduce "new primitives" (quoting the OP),
but is built out of traditional Java "synchronised", "volatile", wait() and
notifyAll(). So you are still taking out locks, but are going through a more
complicated code path to do so. So unless the bottleneck you are trying to fix
is that /while/ one thread is holding a lock, other threads cannot make
progress (rather than the overhead of taking out and releasing the lock), there
will be no performance gain in using the more sophisticated algorithms. Even
then, unless you can actually split the locking behaviour (as in
multiple-readers, single-writer locks) there can be no performance gain. E.g.
if all your threads are modifying a single variable there is no way that you
can split the locking behaviour to allow concurrent writes.

By the way, I don't think the major benefit of the new concurrent package is
improved performance (though there are some clever algorithms) so much as
allowing you to use pre-packaged expressions of standard (and
easy-to-get-wrong) concurrent behaviour. The usual benefits of re-using
code designed by an expert, rather than hacking out a roll-you-own solution
every time.

The new stuff is mostly (maybe entirely, for all I know) written by Doug Lea,
and while his book "Concurrent Programming with Java" pre-dates the new
packages, he discusses (as far as I remember) all the important ideas embodied
in java.util.concurrent, and much besides. I /strongly/ recommend the book.

-- chris

 

[Michael Borgwardt]

I've heard that the concurrency features in 1.5 are more efficient than
using synchronized().

That's bullshit. The concurrency packages *use* synchronized().

They just offer higher levels of abstraction.

 

[Peter Ashford]

That's bullshit. The concurrency packages *use* synchronized().

They just offer higher levels of abstraction.

"By exposing a compare-and-swap operation that the JVM will implement
according to what concurrency features the hardware provides (CAS,
LL/SC, or in the worst case, locking), it becomes practical to write
efficient lock-free algorithms in Java, opening the door to
higher-performance, more scalable implementations for a number of the
classes in java.util.concurrent."

http://today.java.net/pub/a/today/2004/03/01/jsr166.html

 

[Michael Borgwardt]

"By exposing a compare-and-swap operation that the JVM will implement
according to what concurrency features the hardware provides (CAS,
LL/SC, or in the worst case, locking), it becomes practical to write
efficient lock-free algorithms in Java, opening the door to

Hm, so I am proven wrong on that one. Very interesting. But I would have liked to
confirm/get more details on that on the actual JSR page. Unfortunately, the
link provided there points to a host that seems not to exist.

 

[Chris Uppal]

"By exposing a compare-and-swap operation that the JVM will implement
according to what concurrency features the hardware provides (CAS,
LL/SC, or in the worst case, locking), it becomes practical to write
efficient lock-free algorithms in Java, opening the door to
higher-performance, more scalable implementations for a number of the
classes in java.util.concurrent."

http://today.java.net/pub/a/today/2004/03/01/jsr166.html

Interesting, I didn't realise that. Thanks for the link.

BTW, looking at the code, there is no class java.util.concurrent.Lock, as
suggested by the linked article. There are some new compareAndSwapXXX()
methods added to sun.misc.Unsafe, and these are used by some of the collections
classes.

It will be interesting to see what the performance is like (I don't have time
for even simple benchmarking now). Superficially, the code path involved in,
say, acquire()-ing a Semaphore seems very long, so I wouldn't be surprised if
it was (marginally) slower than the traditionaly roll-your-own approach when
running on a uniprocessor machine with a stock CPU. But that is, of course,
pure guesswork.

-- chris

 

[Peter Ashford]

Hm, so I am proven wrong on that one. Very interesting. But I would have
liked to
confirm/get more details on that on the actual JSR page. Unfortunately, the
link provided there points to a host that seems not to exist.

Well, I wanted more details too - hence the original post.

 

[Sudsy]

Peter Ashford wrote:




Interesting, I didn't realise that. Thanks for the link.

BTW, looking at the code, there is no class java.util.concurrent.Lock, as
suggested by the linked article. There are some new compareAndSwapXXX()
methods added to sun.misc.Unsafe, and these are used by some of the collections
classes.

Compare and swap...hmmm...an RS instruction with op code 0xBA, according
to my System/370 Reference Summary. Everything old is new again! ;-)

 

[Thomas G. Marshall]

Sudsy coughed up:

Compare and swap...hmmm...an RS instruction with op code 0xBA,
according to my System/370 Reference Summary. Everything old is new
again! ;-)

Off the top of your head? 6502 nop is 234 (0xea). So there ''''''''''''