CODEWITHSUNDEEP
javamultithreadingconcurrency
AlexGo
AlexGo

Reputation: 487

locking synchronization in java using reentrant lock

I have and application made in java that uses an reentrant global lock and I have a problem like this:

One thread is acquire the reentrant global lock and let say that is keeping the lock 30 seconds in this interval of time it makes some operations. In this interval of time all other threads are blocked. My problem is that I want some threads like RMI to have the chance to execute.

What would be a good locking policy or optimization in order to let some other threads to acquire the lock for a short period of time ?

Upvotes: 0

Views: 612

Answers (3)

Rama Sharma
Rama Sharma

Reputation: 116

I believe this can be achieved via acquiring on only particular section of code by first thread which has global lock for 30 seconds and also you can also use Read and write separate locks which comes with ReadWriteLock Object in java. ReadWriteLock is implemented by ReentrantReadWriteLock Class in java.util.concurrent.locks package.Multiple Threads can acquire multiple read Locks, but only a single Thread can acquire mutually-exclusive write Lock .Other threads requesting readLocks have to wait till the write Lock is released. A thread is allowed to degrade from write lock to read lock but not vice-versa. Allowing a read thread to upgrade would lead to a deadlock as more than one thread can try to upgrade its lock. The ReentrantReadWriteLock also supports all the features of the Reentrant lock like providing the fair mechanism, reentrant locks, Condition Support (on a write Lock only), allowing interruption on read as well as write Locks.

. A Condition object, also known as condition variable, provides a thread with the ability to suspend its execution, until the condition is true. A Condition object is necessarily bound to a Lock and can be obtained using the newCondition() method.

Furthermore, a Condition enables the effect of having multiple wait-sets per object, by combining these sets with the use of a Lock implementation. Moreover, due to the fact that Conditions access portions of state shared among different threads, the usage of a Lock is mandatory. It is important to mention that a Condition must atomically release the associated Lock and suspend the current’s thread execution.

For your reference I am giving you the URLs -> https://examples.javacodegeeks.com/core-java/util/concurrent/locks-concurrent/condition/java-util-concurrent-locks-condition-example/

https://examples.javacodegeeks.com/core-java/util/concurrent/locks-concurrent/readwritelock/java-readwritelock-example/

Please let me know if you need other help

Upvotes: 0

Vipin
Vipin

Reputation: 5223

If one thread has acquired lock other threads cant proceed , we can not change this behavior. Now to solve your problem there are few suggestions I want to give.

Try to Reduce lock scope so that other threads also get chance for execution. Look at the possibility if you can acquire lock for really required part and release lock after that. Because as you said one thread is taking good amount of time there could be some part of code where you don't need locking.

operationInLock(){
----
lock.lock();
Code where lock is required;
lock.unlock();

Code where lock is Not required;
Code where lock is Not required;
Code where lock is Not required;

lock.lock();
Code where lock is required;
lock.unlock();

Code where lock is Not required;
Code where lock is Not required;
Code where lock is Not required;

}

If you don't feel this answer useful , give us some more info about code/functionality because without seeing code it becomes very difficult to give solution we can just give u suggestions based on best practice.

Upvotes: 0

Andrey Chaschev
Andrey Chaschev

Reputation: 16476

So you basically have a job queue which should be executed in a single-threaded environent. Each time before polling from this queue you need to sort it's entries by priority.

abstract class JobEntry<V> implements Callable<V>{
    Date registeredAt;
    long runEstimationMs;
    JobType type;
}

So you could come up with a weighing function for this entry and sort entries based on it or with implementing Comparable.

And this is almost it. You could send these jobs to a fixed thread pool of a single thread. If you need to interrupt them, you would need to cancel the future and each job should check Thread.interrupted() state.

The most difficult part here is the weighing function, a possible way to build it could be making a set of experiments on your system.

Upvotes: 2

Related Questions