Q1. What is a condVar in Java? If I see the code below, does a condition variable necessarily have to be within the 'mutex.acquire()' and 'mutex.release()' block?
public void put(Object x) throws InterruptedException {
mutex.acquire();
try {
while (count == array.length)
notFull.await();
array[putPtr] = x;
putPtr = (putPtr + 1) % array.length;
++count;
notEmpty.signal();
}
finally {
mutex.release();
}
}
I have three threads myThreadA, myThreadB, myThreadC running which call the same function commonActivity() which triggers the function myWorkReport() e.g.
public void myWorkReport(){
mutexMyWork.acquire();
try{
while(runMyWork){
doWork();
conditionMyWork.timedwait(sleepMyWork);
}
}
finally{
mutexMyWork.release()
}
}
public void commonActivity(){
try{
conditionMyWork.signal();
}finally{
//cleanup
}
}
public void myThreadA(){
mutexA.acquire();
try{
while(runningA){ //runningA is a boolean variable, this is always true as long as application is running
conditionA.timedwait(sleepA);
commonActivity();
}
}
finally{
mutexA.release();
}
}
public void myThreadB(){
mutexB.acquire();
try{
while(runningB){ //runningB is a boolean variable, this is always true as long as application is running
conditionB.timedwait(sleepB);
commonActivity();
}
}
finally{
mutexB.release();
}
}
public void myThreadC(){
mutexC.acquire();
try{
while(runningC){ //runningC is a boolean variable, this is always true as long as application is running.
conditionC.timedwait(sleepC);
commonActivity();
}
}
finally{
mutexC.release();
}
}
Q2. Is using timedwait a good practice. I could have achieved the same by using sleep(). If using sleep() call is bad, Why?
Q3. Is there any better way to do the above stuff?
Q4. Is it mandatory to have condition.signal() for every condition.timedwait(time);
Q1) The best resource for this is probably the JavaDoc for the Condition class. Condition variables are a mechanism that allow you to test that a particular condition holds true before allowing your method to proceed. In the case of your example there are two conditions, notFull and notEmpty.
The put method shown in your example waits for the notFull condition to become true before it attempts to add an element into the array, and once the insertion completes it signals the notEmpty condition to wake up any threads blocked waiting to remove an element from the array.
...does a condition variable necessarily
have to be within the
'mutex.acquire()' and
'mutex.release()' block?
Any calls to change the condition variables do need to be within a synchronized region - this can be through the built in synchronized keyword or one of the synchronizer classes provided by the java.util.concurrent package such as Lock. If you did not synchronize the condition variables there are two possible negative outcomes:
A missed signal - this is where one thread checks a condition and finds it does not hold, but before it blocks another thread comes in, performs some action to cause the condition to become true, and then signals all threads waiting on the condition. Unfortunately the first thread has already checked the condition and will block anyway even though it could actually proceed.
The second issue is the usual problem where you can have multiple threads attempting to modify the shared state simultaneously. In the case of your example multiple threads may call put() simultaneously, all of them then check the condition and see that the array is not full and attempt to insert into it, thereby overwriting elements in the array.
Q2) Timed waits can be useful for debugging purposes as they allow you to log information in the event the thread is not woken up via a signal.
Using sleep() in place of a timed wait is NOT a good idea, because as mentioned above you need to call the await() method within a synchronized region, and sleep() does not release any held locks, while await() does. This means that any sleeping thread will still hold the lock(s) they have acquired, causing other threads to block unnecessarily.
Q4) Technically, no you don't need to call signal() if you're using a timed wait, however, doing so means that all waits will not return until the timeout has elapsed, which is inefficient to say the least.
Q1:
A Condition object is associated (and acquired from) a Lock (aka mutext) object. The javadoc for the class is fairly clear as to its usage and application. To wait on the condition you need to have acquired the lock, and it is good coding practice to do so in a try/finally block (as you have). As soon as the thread that has acquired the lock waits on a condition for that lock, the lock is relinquished (atomically).
Q2:
Using timed wait is necessary to insure liveness of your program in case where the condition you are waiting for never occurs. Its definitely a more sophisticated form, and it is entirely useless if you do not check for the fact that you have timed out and take action to handle the time out condition.
Using sleep is an acceptable form of waiting for something to occur, but if you are already using a Lock ("mutex") and have a condition variable for that lock, it make NO sense not to use the time wait method of the condition:
For example, in your code, you are simply waiting for a given period but you do NOT check to see if condition occurred or if you timed out. (That's a bug.) What you should be doing is checking to see if your timed call returned true or false. (If it returns false, then it timed out & the condition has NOT occured (yet)).
public void myThreadA(){
mutexA.acquire();
try{
while(runningA){ //runningA is a boolean variable
if(conditionA.await (sleepATimeoutNanos))
commonActivity();
else {
// timeout! anything sensible to do in that case? Put it here ...
}
}
}
finally{
mutexA.release();
}
}
Q3: [edited]
The code fragments require a more detailed context to be comprehensible. For example, its not entirely clear if the conditions in the threads are all the same (but am assuming that they are).
If all you are trying to do is insure commonActivity() is executed only by one thread at a time, AND, certain sections of the commonActivity() do NOT require contention control, AND, you do require the facility to time out on your waits, then, you can simply use a Semaphore. Note that sempahore has its own set of methods for timed waits.
If ALL of the commonActivity() is critical, AND, you really don't mind waiting (without timeouts) simply make commonActivity() a synchronized method.
[final edit:)]
To be more formal about it, conditions are typically used in scenarios where you have two or more thread co-operating on a task and you require hand offs between the threads.
For example, you have a server that is processing asynchronous responses to user requests and the user is waiting for fulfillment of a Future object. A condition is perfect in this case. The future implementation is waiting for the condition and the server signals its completion.
In the old days, we would use wait() and notify(), but that was not a very robust (or trivially safe) mechanism. The Lock and Condition objects were designed precisely to address these shortcomings.
(A good online resource as a starting point)
Buy and read this book.
Q1. Condition variables are part of monitors facility which is sometimes used for threads synchronization. I don't recognize this particular implementations but usually conditional variables usage must be done in the critical section, thus mutex.acquire and release are required.
Q2. timedwait waits for signal on condition variable OR time out and then reqcquires critical section. So it differs from sleep.
Q3. I am not sure, but I think you may use built-in monitors functionality in java: synchronized for mutual exclusion and wait and notify instead of cond vars. Thus you will reduce dependencies of your code.
Q1. I think documentation gives quite good description. And yes, to await or signal you should hold the lock associated with the condition.
Q2. timedWait is not in Condition API, it's in TimeUnit API. If you use Condition and want to have a timeout for waiting use await(long time, TimeUnit unit). And having a timeout is generally a good idea - nobody wants a program to hang forever - provided you know what to do if timeout occurs.
Sleep is for waiting unconditionally and await is for waiting for an event. They have different purposes.
Q3. I don't know what this code is expected to do. If you want to perform some action cyclically, with some break between each iteration, use sleep instead of conditions.
Q4. As I wrote above conditions don't have timedwait method, they have await method. And calling await means you want to wait for some event to happen. This assumes that sometimes this event does happen and someone signals this. Right?
Q1. I believe by "condition variable", you're referring to something you check to determine the condition that you waited on. For example - if you have the typical producer-consumer situation, you might implement it as something like:
List<T> list;
public T get()
{
synchronized (list)
{
if (list.get(0) == null)
{
list.wait();
}
return list.get(0);
}
}
public void put(T obj)
{
synchronized (list)
{
list.add(obj);
list.notify();
}
}
However, due to the potential of spurious thread wakeups, it is possible for the consumer method to come out of the wait() call while the list is still empty. Thus it's good practice to use a condition variable to wait/sleep/etc. until the condition is true:
while (list.get(0) == null)
{
list.wait();
}
using while instead of if means that the consumer method will only exit that block if it definitely has something to return. Broadly speaking, any sleep or wait or blocking call that was triggered by a condition, and where you expect the condition to change, should be in a while block that checks that condition every loop.
In your situation you're already doing this with the while (count == array.length) wrapper around notFull.await().
Q2. Timed wait is generally a good practice - the timeout allows you to periodically perform a sanity check on your environment (e.g. has a shutdown-type flag been flipped), whereas a non-timed wait can only be stopped by interruption. On the other hand, if the wait is going to just keep blocking anyway until the condition is true, it makes little difference it it wakes up every 50 ms (say) until the notify() happens 2 seconds later, or if it just blocks constantly for those 2 seconds.
As for wait() vs sleep() - the former is generally preferable, since it means you get woken up as soon as you are able to take action. Thread.sleep(500) means that this thread is definitely not doing anything for the next 500ms, even if the thing it's waiting for is ready 2ms later. obj.wait(500) on the other hand would have been woken up 2ms into its sleep and can continue processing. Since sleeps introduce unconditional delays in your program, they're generally a clunkier way to do anything - they're only suitable when you're not waiting on any specific condition but actually want to sleep for a given time (e.g. a cleanup thread that fires every 60 seconds). If you're "sleeping" because you're waiting for some other thread to do something first, use a wait() (or other synchronous technique such as a CountDownLatch) instead.
Q3. Pass - it looks like there's a lot of boilerplate there, and since the code doesn't have any comments in and you haven't explained what it's supposed to do and how it's meant to behave, I'm not going to try and reverse-engineer that from what you're written. ;-)
Related
I've got a system with many writers and a single reader, each running in a separate thread. The writers notify the reader when work is available, and the reader blocks until it is notified.
Given the number of writers, I want to use a lock-free implementation to notify the reader. Every time the reader wakes up, it resets the notification flag, does some work, and blocks waiting for more notifications to arrive.
Essentially I'm looking for the equivalent of an AtomicBoolean with an ability to block until its value becomes true.
What I've tried so far:
My current implementation uses a Semaphore.
The semaphore starts out with no permits.
The reader blocks trying to acquire a permit.
Writers invoke Semaphore.release() in order to notify the reader.
The reader invokes Semaphore.drainPermits(), does some work, and blocks again on Semaphore.acquire.
What I don't like about the Semaphore approach:
It seems a bit heavy-handed. I only care about about the first notification arriving. I don't need to keep a count of how many other notifications came in.
Semaphores throw an exception if their count surpasses Integer.MAX_VALUE. This is more of a theoretical problem than practical but still not ideal.
Is there a data structure that is equivalent to AtomicBoolean with an ability to block waiting on a particular value?
Alternatively, is there a thread-safe manner to ensure that Semaphore's number of permits never surpass a certain value?
BlockingQueue<Singleton> would do this adequately.
You would create, for example, an ArrayBlockingQueue<Singleton>(1), and then your waiter would look like:
queue.take();
… and the notifier would look like:
queue.offer(Singleton.INSTANCE)
… with the use of offer ensuring that multiple releases are combined together.
FYI: The Java language includes a general mechanism for threads to await arbitrary events caused by other threads. It's rather primitive, and in many applications, you'd be better off using some higher-level, problem-specific tool such as BlockingQueue, CompletableFuture, CountdownLatch, etc. But, for those problems where the higher-level classes all "feel a bit heavy-handed," the Object class has object.wait(), object.notify(), and object.notifyAll().*
The idea is,
You have some test() that yields a boolean result,
There is a mutex that threads are required to own when performing the test or changing its result, and
There is at least one thread that needs to wait until the test yields true before it can proceed.
final Object mutex = new Object();
public boolean test() { ... }
public boolean procedureThatAffectsTheTestResult() { ... }
public boolean procedureThatRequiresTestResultToBeTrue() { ... }
A thread that needs to wait until the test result is true can do this:
synchronized (mutex) {
while (! test()) {
try {
mutex.wait();
}
catch (InterruptedException ex) {
...use your shameful imagination here...
}
}
procedureThatRequiresTestResultToBeTrue();
}
Any thread that can change the test result should do it like so:
synchronized (mutex) {
procedureThatAffectsTheTestResult();
mutex.notifyAll(); //or, mutex.notify() *IF* you know what you are doing.
}
The mutex.notifyAll() call will wake up every thread that happens to be sleeping in a mutex.wait() call at that same moment. mutex.notify() is trickier, but it will improve the performance of some applications because it will arbitrarily choose just one thread if more than one is waiting.
You may be wondering how a thread could ever enter a synchronized (mutex) block to change the test() result when another thread already is wait()ing inside another synchronized (mutex) block. The secret is that mutex.wait() temporarily unlocks the mutex while it is waiting, and then it guarantees to re-lock the mutex before returning or throwing an exception.
For a more complete description of when and why and how to use this feature, see the tutorial: https://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html
* You can also do practically the same thing using a Condition object and a ReentrantLock, but that's a topic for another day.
From Programming Language Pragmatics, by Scott
Java objects that use only synchronized methods (no locks or
synchronized statements) closely resemble Mesa monitors in which
there is a limit of one condition variable per monitor (and in fact
objects with synchronized statements are sometimes referred to as
monitors in Java).
Why are Java objects that use only synchronized methods closely resemble Mesa monitors in which there is a limit of one condition variable per monitor?
Is it correct that there is no condition variable in "Java objects that use only synchronized methods"? So how can it resembles a monitor with one condition variable?
By the same token, a synchronized statement in Java that begins
with a wait in a loop resembles a CCR in which the retesting of
conditions has been made explicit. Because notify also is explicit,
a Java implementation need not reevaluate conditions (or wake up
threads that do so explicitly) on every exit from a critical
section—only those in which a notify occurs.
Why does a synchronized statement in Java that begins
with a wait in a loop resembles a CCR (conditional critical region) in which the retesting of conditions has been made explicit?
What does it mean by "Because notify also is explicit, a Java implementation need not reevaluate conditions (or wake up threads that do so explicitly) on every exit from a critical section—only those in which a notify occurs"?
Thanks.
All this is saying is that in Java intrinsic locks have the condition baked into them. Contrast this with ReentrantLock where you can explicitly have separate conditions with the same lock.
If you have separate conditions then you can signal a given condition and know only threads in the wait set for that condition will receive it. If you don't have separate condition objects then upon being notified you have to check to see if that condition applies to you.
An example of this would be a fixed size blocking queue. If you look at ArrayBlockingQueue, it's implemented with ReentrantLock so that putting and taking use separate condition objects. If this was implemented using the intrinsic lock on the Queue object it would have to use notifyAll to wake up waiting threads, which would then have to test the condition they woke up from waiting on to find out if it was relevant to them.
Here is a blocking queue written using an intrinsic lock. If notify was used then a single thread would be woken by the scheduler and (since threads could be waiting to put or waiting to take) it might or might not be one that the notify was relevant to. To make sure the notification doesn't get lost all the waiting threads get notified:
public class Queue<T>{
private final int maxSize;
private List<T> list = new ArrayList<>();
public Queue(int maxSize) {
this.maxSize = maxSize;
}
public synchronized T take() throws InterruptedException {
while (list.size() == 0) {
wait();
}
notifyAll();
return list.remove(0)(
}
public synchronized void put(T entry) throws InterruptedException {
while (list.size() == maxSize) {
wait();
}
list.add(entry);
notifyAll();
}
}
hi guys i was wondering if i can get a little advice im trying to write a program that can counts how many threads are waiting to process a function, and then once a certain number is achieved it releases all the thread. but my problem is i cant increment properly being that i can the all process the increment code at the same time , thus not incrementing it at all.
protected synchronized boolean isOpen()
{
//this code just calls mymethod intrested where the problem lies
lock.interested();
while(!lock.isReady())
{
}
return true;// this statement releases all my threads
}
public synchronized void interested()
{
count++;// how do i make this increment correctly with threads
System.out.println(count+"-"+ lanes+"-"+ThreadID.get());
if(count==lanes)
{
count =0;
ready =true;
}
}
The problem with your approach is that only one thread can enter the synchronized method at a time and hence, you will never proceed, as all but the first threads are waiting to enter the synchronized method while the first thread is performing a busy-wait loop. You have to use wait which not only solves the waste of CPU cycles of your busy wait but will also free the associated lock of the synchronized code so that the next thread can proceed:
protected synchronized boolean isOpen()
{
lock.interested();
while(!lock.isReady())
{
wait(); // now the next thread can enter isOpen()
}
notify(); // releases the previous thread wait()ing in this method
return true;
}
However, note that this works quite unreliable due to your code being split over multiple different objects. It’s strongly recommend to put the code maintaining the counter and code implementing the waiting for the counter into one object in order to run under the same lock. Your code structure must ensure that interested() can’t be invoked on the lock instance with isOpen not noticing. From the two code fragments you have posted, it’s impossible to deduce whether this is the case.
write a program that can counts how many threads are waiting to
process a function, and then once a certain number is achieved it
releases all the threads
A good solution will be to use CountDownLatch.
From the manual:
A CountDownLatch is initialized with a given count. The await methods
block until the current count reaches zero due to invocations of the
countDown() method, after which all waiting threads are released and
any subsequent invocations of await return immediately. This is a
one-shot phenomenon -- the count cannot be reset. If you need a
version that resets the count, consider using a CyclicBarrier.
You can find a good code example here
You should not use synchronised. Because only one thread will acquire monitor at a time.
You can use CountDownLatch. Just define the no of threads while initialising CountDownLatch.
private CountDownLatch countDownLatch = new CountDownLatch(no_of_threads);
protected boolean isOpen()
{
//this code just calls mymethod intrested where the problem lies
countDownLatch.countDown();
countDownLatch.await();
return true;// this statement releases all my threads
}
All the threads are waiting in countDownLatch.await(). Once the required amount of thread comes(countDownLatch.countDown() is called) it will allow to proceed.
I wrote this method whose purpose is to give notice of the fact that a thread is leaving a
specific block of code
A thread stands for a car which is leaving a bridge so other cars can traverse it .
The bridge is accessible to a given number of cars (limited capacity) and it's one way only.
public void getout(int diection){
// release the lock
semaphore.release();
try{
lock.lock(); //access to shared data
if(direction == Car.NORTH)
nNordTraversing--; //decreasing traversing threads
else
nSudTraversing--;
bridgeCond.signal();
}finally{
lock.unlock();
}
}
My question is: should I use lock.lock(); or it's just nonsense?
thanks in advance
As we don't have the complete code (what is that semaphore ?), this answer is partly based on guess.
If your question is related to the increment and decrement operations, then you should know that those operation aren't, in fact, atomic.
So yes, if you have other threads accessing those variables, you need to protect them to ensure that no other thread can read them or worse try to do the same operation, as two parallel increments may result in only one effective.
But as locking has a cost, you may also encapsulate your variable in AtomicLong.
From the code snippet and requirement getout will not be called by simulatenous thread, only thread which is at the front of the queue, hence the method which is calling getout should be synchronized, as not all threads(cars) can be at the front of the queue.
I also think you are using semaphore as your guard lock in the calling method.
If in your implementation getout is being called by multiple methods then yes you need synchronization and your code is correct.
Well, I assume that nNordTraversing and nSudTraversing are shared data. Since ++ and -- are not atomic operations it is sensefull to lock them, before changing. Otherwise what could happen is the following:
you read the variable nNordTraversing (e.g. 7)
another Thread gets scheduled and completes its getout method, it changed the variable (e.g. 7 -- --> 6)
you are scheduled back, change the variable but on the old data you read (e.g. 7 --> 8)before the other thread changed it
the changes of the other thread got over written, the count is not consistent anymore (e.g. its 8 now, but should be 7)
This is called the lost update problem.
I am writing a simple threading application. Thread is simply a message consumer and process it. However, if the thread somehow got interrupted and the message is not fully processed, I want to put it back to the queue and let other instances get it. So I had to code it like this:
public void run()
{
Map<String, String> data = null;
try
{
while(true)
{
data = q.getData();
System.out.println(this+" Processing data: "+data);
// let others process some data :)
synchronized(this){
sendEmail(data);
data = null;
}
}
}
catch (InterruptedException e)
{
System.out.println(this+" thread is shuting down...");
if(null!=data)
q.add(data);
}
}
Thanks...
EDIT: Thanks for the responses. Everything is very clear now. I understand that even when lines of codes are in a synchronized block, if any of them can throw InterruptedException then it simply means they can be interrupted at that point. The line q.getData() enters this thread to a 'blocked' state (I am using LinkedBlockedQueue inside the q.getData()). At that point, this thread can be interrupted.
A thread will not catch an InterruptedException any time another thread calls interrupt() on it, nor does that method magically stop whatever it's doing. Instead, the method sets a flag that the thread can read using interrupted(). Certain other methods will check for this flag and raise InterruptedException if it's set. For example, Thread.sleep() and many I/O operations which wait for an external resource throw it.
See the Java Thread Interrupts Tutorial for more information.
In addition to David Harkness's answer: you also don't understand meaning of synchronized keyword.
Synchornized is not a kind of "atomic" or "uninterruptable" block.
Synchornized block doesn't provide any guarantees other than that other threads can't enter synchronized block on the same object (this in your case) at the same time (+ some memory consistency guarantees irrelevant in your case).
Therefore usage of synchornized in your case is pointless, since there is no need to protect data from concurrent access of other threads (also, you are synchronizing on this, I don't think other threads would synchronize on the same object).
See also:
Synchronization
Ignoring for the moment that while(true) puts the thread into a CPU loop...
If sendMail does anything that checks for thread interruption it will throw an interrupted exception. So the answer to your question is likely to be a solid yes, the thread can be interrupted within the synchronized block, and you will have to catch the exception and check for that.
That said, InterruptedException is a checked exception, so short of funny buggers being done at a lower level, sendMail should indicate that it can throw InterruptedException.
Yes
Java synchronization means no other thread can access the same lock while a thread has acquired it.
If you don't want any other thread to be able to access a message (or any other object) use synchronized(message) block.