I’m trying to understand how threads work in Java and currently investigating how to implement looped threads that can be cancelled. Here’s the code: The thread I create is indended to be interrupted sooner or later. So, I check isInterrupted() flag to decide whether I need to go on and also catch InterruptedException to handle cases when I’m in a
Tag: multithreading
What are the main uses of yield(), and how does it differ from join() and interrupt()?
I am a little bit confused about the use of Thread.yield() method in Java, specifically in the example code below. I’ve also read that yield() is ‘used to prevent execution of a thread’. My questions are: I believe the code below result in the same output both when using yield() and when not using it. Is this correct? What are,
Does any JVM implement blocking with spin-waiting?
In Java Concurrency in Practice, the authors write: When locking is contended, the losing thread(s) must block. The JVM can implement blocking either via spin-waiting (repeatedly trying to acquire the lock until it succeeds) or by suspending the blocked thread through the operating system. Which is more efficient depends on the relationship between context switch overhead and the time until
is there a ‘block until condition becomes true’ function in java?
I’m writing a listener thread for a server, and at the moment I’m using: With the code above, I’m running into issues with the run function eating all the cpu time looping. The sleep function works, but it seems be a makeshift fix, not a solution. Is there some function which would block until the variable ‘condition’ became ‘true’? Or
In java, how to wait on multiple `Conditions` until any one of them is signaled
Suppose an elevator simulation program, visitors about to take a ride are to wait until any one of the elevator doors opens. i.e. I want to wait on multiple Conditions until any one of them is signaled. Actually, it doesn’t have to be Conditions, other approaches that can fulfill my need is welcome. How can this be done in Java?
“Java DateFormat is not threadsafe” what does this leads to?
Everybody cautions regarding Java DateFormat not being thread safe and I understand the concept theoretically. But I’m not able to visualize what actual issues we can face due to this. Say, I’ve a DateFormat field in a class and the same is used in different methods in the class (formatting dates) in a multi-threaded environment. Will this cause: any exception
wait() and notify() method , always IllegalMonitorStateException is happen and tell me current Thread is not Owner Why?
Answer You need to hold the lock on the object you want to wait on (you can only call it within a synchronized block). Also, calling wait on a Thread is very unusual and probably not what you want. I am not sure what you are trying to do, but could you be confusing wait with sleep? If you want
Why do threads share the heap space?
Threads each have their own stack, but they share a common heap. Its clear to everyone that stack is for local/method variables & heap is for instance/class variables. What is the benefit of sharing heap among threads. There are several number of threads running simultaneously, so sharing memory can lead to issues such as concurrent modification, mutual exclusion etc overhead.
JUnit terminates child threads
When I test the execution of a method that creates a child thread, the JUnit test ends before the child thread and kills it. How do I force JUnit to wait for the child thread to complete its execution? Answer After reading the question and some comments, it seems that what you need is a technique for unit testing asynchronous
Why must wait() always be in synchronized block
We all know that in order to invoke Object.wait(), this call must be placed in synchronized block, otherwise an IllegalMonitorStateException is thrown. But what’s the reason for making this restriction? I know that wait() releases the monitor, but why do we need to explicitly acquire the monitor by making particular block synchronized and then release the monitor by calling wait()?