Monday, January 9, 2012

Chapter 10: Explicit Locking of Objects


In the previous chapters we learnt about the “Synchronized Keyword” and how the whole “Synchronization & Race Condition” concept works. To recap, the purpose of the synchronized keyword is to provide the ability to allow serialized entrance to synchronized methods in an object. Although almost all the needs of data protection can be accomplished with this keyword, it is too primitive when the need for complex synchronization arises. More complex cases can be handled by using classes that achieve similar functionality as the synchronized keyword.

Using the Synchronized keyword automatically captures & releases locks when threads execute. But, starting J2SE 5.0, a developer can explicitly capture and release locks on objects. Sounds cool doesn’t it? This is exactly what we are going to learn in this chapter.

The synchronization tools in J2SE 5.0 implement a common interface: the Lock interface. For this chapter, the two methods of this interface that are important to us are lock( ) and unlock(). Using the Lock interface is similar to using the synchronized keyword: we call the lock() method at the start of the method and call the unlock() method at the end of the method, and we've effectively synchronized the method.

The lock() method grabs the lock. The difference is that the lock can now be more easily envisioned, we now have an actual object that represents the lock. This object can be stored, passed around, and even discarded. As before, if another thread owns the lock, a thread that attempts to acquire the lock waits until the other thread calls the unlock() method of the lock. Once that happens, the waiting thread grabs the lock and returns from the lock( ) method. If another thread then wants the lock, it has to wait until the current thread calls the unlock() method.

In terms of functionality, the code works exactly the same way as it would work with the Synchronized keyword. But, there is a minor difference. The difference is that by using a lock class, we can now utilize other functionality, that can't be accomplished by just using the synchronized keyword.

Using a lock class, we can now grab and release a lock whenever desired. We can test conditions before grabbing or releasing the lock. And since the lock is no longer attached to the object whose method is being called, it is now possible for two objects to share the same lock. It is also possible for one object to have multiple locks. Locks can be attached to data, groups of data, or anything else, instead of just the objects that contain the executing methods.

This is the cool advantage of using “Explicit Locking”.

The Lock Interface

Before we wrap up this chapter, let's look a little deeper into the Lock interface. The Lock interface code would look like below:
public interface Lock {
void lock( );
void lockInterruptibly( ) throws InterruptedException;
boolean tryLock( );
boolean tryLock(long time, TimeUnit unit)
throws InterruptedException;
void unlock( );
Condition newCondition( );
}

Lets understand the key methods of this class that we will use in real life:

lock() – this is the method you will use to obtain the lock. If the lock is not available, it waits until the lock is available.
tryLock() – this method is similar to the lock() method but, if the lock is not available, it does not wait and returns a boolean value of false. If the lock is obtained, it returns true
tryLock(long time, TimeUnit unit) – this method is similar to the tryLock() method with a small difference. You can specify the time period that this method has to wait, in case a lock is not available right away. The time passed as argument is the maximum time this method will wait for the lock
unlock() – this method is used to release/relenquish the lock

Previous: Race Conditions

Next: Lock Scope

No comments:

Post a Comment

© 2013 by www.inheritingjava.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.

ShareThis

Google+ Followers

Followers