Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 


Eclipse Platform
Release 3.5

org.eclipse.core.runtime.jobs
Interface ILock


public interface ILock

A lock is used to control access to an exclusive resource.

Locks are reentrant. That is, they can be acquired multiple times by the same thread without releasing. Locks are only released when the number of successful acquires equals the number of successful releases.

Locks are capable of detecting and recovering from programming errors that cause circular waiting deadlocks. When a deadlock between two or more ILock instances is detected, detailed debugging information is printed to the log file. The locks will then automatically recover from the deadlock by employing a release and wait strategy. One thread will lose control of the locks it owns, thus breaking the deadlock and allowing other threads to proceed. Once that thread's locks are all available, it will be given exclusive access to all its locks and allowed to proceed. A thread can only lose locks while it is waiting on an acquire() call.

Successive acquire attempts by different threads are queued and serviced on a first come, first served basis.

It is very important that acquired locks eventually get released. Calls to release should be done in a finally block to ensure they execute. For example:

 try {
        lock.acquire();
        // ... do work here ...
 } finally {
        lock.release();
 }
 
Note: although lock.acquire should never fail, it is good practice to place it inside the try block anyway. Releasing without acquiring is far less catastrophic than acquiring without releasing.

Since:
3.0
See Also:
IJobManager.newLock()
Restriction:
This interface is not intended to be implemented by clients.
Restriction:
This interface is not intended to be extended by clients.

Method Summary
 void acquire ()
          Acquires this lock.
 boolean acquire (long delay)
          Attempts to acquire this lock.
 int getDepth ()
          Returns the number of nested acquires on this lock that have not been released.
 void release ()
          Releases this lock.
 

Method Detail

acquire

boolean acquire(long delay)
                throws 
InterruptedException
Attempts to acquire this lock. If the lock is in use and the specified delay is greater than zero, the calling thread will block until one of the following happens:
  • This lock is available
  • The thread is interrupted
  • The specified delay has elapsed

While a thread is waiting, locks it already owns may be granted to other threads if necessary to break a deadlock. In this situation, the calling thread may be blocked for longer than the specified delay. On returning from this call, the calling thread will once again have exclusive access to any other locks it owned upon entering the acquire method.

Parameters:
delay - the number of milliseconds to delay
Returns:
true if the lock was successfully acquired, and false otherwise.
Throws:
InterruptedException - if the thread was interrupted

acquire

void acquire()
Acquires this lock. If the lock is in use, the calling thread will block until the lock becomes available. If the calling thread owns several locks, it will be blocked until all threads it requires become available, or until the thread is interrupted. While a thread is waiting, its locks may be granted to other threads if necessary to break a deadlock. On returning from this call, the calling thread will have exclusive access to this lock, and any other locks it owned upon entering the acquire method.

This implementation ignores attempts to interrupt the thread. If response to interruption is needed, use the method acquire(long)


getDepth

int getDepth()
Returns the number of nested acquires on this lock that have not been released. This is the number of times that release() must be called before the lock is freed.

Returns:
the number of nested acquires that have not been released

release

void release()
Releases this lock. Locks must only be released by the thread that currently owns the lock.


Eclipse Platform
Release 3.5

Guidelines for using Eclipse APIs.

Copyright (c) Eclipse contributors and others 2000, 2008. All rights reserved.


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire