Skip to main content

Locks vs Monitors

6 replies [Last post]
linuxhippy
Offline
Joined: 2004-01-07

Hi,

I wonder what your performance experiences are when using Locks or Monitors for synchronization.
I plan to synchronize some slightly contended (_most_ of the time uncontended) code, and well the choice is between Locks or traditional Monitors.

I've heard that Locks scale much better under contention, but I wonder wether this is still true with JDK6.
On the contrary some optimizations such as lock coarsening are only implemented for monitors. (Sadly biased locking doesn't work for me, because the object is alloaced in the first 4s after startup)
What I wonder is wether there is an upper limited for the method size of the synchronized methods.

What are your experiences with synchronization performance?

Thanks, Clemens

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
peter__lawrey
Offline
Joined: 2005-11-01

> Hi,
>
> I wonder what your performance experiences are when using Locks or Monitors for synchronization.
I have found ReentrantLock is 2-3 time faster than synchronized when there is more than one thread which acquires it. This appears to depend on the hardware and OS used as to what the ratio is.
If you use biased locking and there is typically only one thread which acquires the lock, then the locking time is much the same.
Something which appears to be just as significant is that a synchronized block tries to ensure all the data is correctly in shared memory. So if you update lot of memory in a synchronized block, it can be very slow.
Locks don't offer this protection so you may need to use volatile for shared field.
> I've heard that Locks scale much better under
> contention, but I wonder wether this is still true
> with JDK6.
This is still true in JDK6.
> What I wonder is wether there is an upper limited for
> the method size of the synchronized methods.
Its the same limit as non-synchronized methods. A method cannot have more than 64K bytes of byte code. (due to a JVM limit)
However you can call other methods from a synchronized method.

linuxhippy
Offline
Joined: 2004-01-07

Hi Peter,

> Something which appears to be just as significant is
> that a synchronized block tries to ensure all the
> data is correctly in shared memory. So if you update
> lot of memory in a synchronized block, it can be very
> slow.
> Locks don't offer this protection so you may need to
> use volatile for shared field.

Hmm, thats strange, I thought both monitors and locks guarantee consistency - do you have any links about that? As far as I know both, monitors and Locks are implemented by lock cmpxchg at least on x86.

> Its the same limit as non-synchronized methods. A
> method cannot have more than 64K bytes of byte code.
> (due to a JVM limit)
Sorry I didn't make this very clear. Do you know wether there is an upper size limit for lock coarsening a method may have?

Thanks, Clemens

peter__lawrey
Offline
Joined: 2005-11-01

Monitors and locks apply to objects. There is no limit to how long you can hold the lock or the amount of code.

linuxhippy
Offline
Joined: 2004-01-07

> Monitors and locks apply to objects. There is no
> limit to how long you can hold the lock or the amount
> of code.
Sure, but I was talking about lock elimination through lock coarsening, which is done since JDK6.
Would be quite interesting to know the restrictions when a lock can't be coarsed anymore (too many bytecodes in between, ....). I asked on hsruntime-openjdk, maybe they know more about it.

Do you know any link or paper that clarifies the memory-barrier behaviour of locks vs. monitors?
I am a bit afraid I misunderstood things in the past.

Thanks, Clemens

fred34
Offline
Joined: 2004-06-19

As far as I know, Synchronisers and implicit sychronisation offer the same data visibility guarentees, they certainly offer the same behavior in terms of mutex.

The Javadocs here: http://java.sun.com/javase/6/docs/api/

and the package description here: http://java.sun.com/javase/6/docs/api/

mention the details on memory-consistency, i.e. data visibility. Also Brian Goetz has written much on the subject: http://www.ibm.com/developerworks/java/library/j-jtp10264/ speaks about ReentrantLocks.

Those links should be good to start with, but he has written tonnes of other articles on synchronisation and memory semantics.

linuxhippy
Offline
Joined: 2004-01-07

Hi Fred,

Thanks for mentioning this. I also got a mail from Dave Dice, that there's no difference between Locks and monitors when it comes to the memory model.
Was quite glad to hear that, guess I would have to rewrite a lot of code if that wouldn't hold ;)

Thanks, Clemens