i have multiple threads, who all run from one object.
i want the "main thread" to run alone until a certain point, then it waits and all the other threads run together, then the main thread wakes, etc.....
i am having trouble synchronizing my threads. i either get an Illegal Monitor State Exception, or it gets stuck in one of the "wait" loops that are suppose to receive a "notify" that never arrives.
more specifically, i have an object with an array. each cell in the array has a thread that checks the adjacent cells and then changes it's cell with that information.
in order to make the changes orderly, i want all the cells to first make the check of their adjacent cells and keep the value they produced, then wait.
when all of them are done, the main thread will wake all of them up and they will update their respective cells.
i looked up how "wait" and "notify" work, but i still don't understand how they sync. from what i understand i need to connect them all to one object, and then that object is the "lock", so if i use "synchronize" on its methods only one thread can approach it at a time? how can i make sure a "wait" method will always have a "notify" to end it?
Edit:
the method basically runs Conway's game of life.
the main orientation of the code is like so:
the class LifeMatrix extends JPanel. it had an array of panels, each is either "dead or alive" (true/false). the class RunMatrixThread extends thread, and is the "main thread" that coordinates the code. the class CellThead extends thread, and a CellThread is made for every cell in the matrix.
so my idea was to give all the threads the "LifeMatrix" as an observer, but if i try to notify the LifeMatrix Object (with matrix.notify()) it gives me the Illigal Monitor State Exception, and if i try to use "notify all" it gets stuck in RunMatrixThread's wait() command.
also, do i notify an object? or do i notify the threads that are waiting?
Don't use parallelization. Before using threads think if you really can parallelize your job because if all of your tasks have to be sync with each other use threads won't give you better perfomance in terms of execution time. Say that you have an array of objects [a,b] if a must waiting for some changes on b, you can't treat a and b separately so you can't parallelize your job. On the contrary if you need to process a, b and all the elements of your array and at the end perform some computation on them you can Join the threads with join() method. When you call join method you basically join threads branches in one (the main thread). A new thread will fork your main thread and join will join these threads.
If you're trying to get "worker threads" to do parcels of work that are authorized/initiated/doled-out by a "main" thread, then you probably should be using a thread pool (e.g, https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadPoolExecutor.html)
A thread pool takes care of creating the worker threads and "synchronizing" their activity with the main thread, and it lets you focus on the task (or tasks) that the workers perform.
each cell in the array has a thread that...
For Conway's Life, that's way too many worker threads. If the work is purely compute-bound, then there's no point in having many more threads than your host has processors to execute them.
If I was coding life for a host with N processors, I would use a thread pool that had N threads. And, In each generation, I would have the main thread submit N tasks to the pool: Each task would do one horizontal stripe of the board.
Ok, first of all i want to thank all of you for trying to help, some of the links you gave me were very helpful.
I found out what my problem was: i was trying to use wait/notify methods from 2 different types of threads at the same time, on the same object. i had the 'CellThread' that used wait and 'notifyAll', and i had the 'RunMatrixThread' that did the same. they of course had "synchronized" methods, but because they were 2 different TYPES of threads, the two types weren't in sync with EACH OTHER.
what solved the problem was that i made 2 new synchronized methods within the 'RunMatrixThread' class, one for waiting and one for notifying, and then just called those methods from all threads (from both thread classes) whenever i wanted to wait/notify. in this way, there was a unified object that had a lock on everything.
PS: i know its a bad idea to use so many threads. it was the coarse's assignment, and they required we do it this way.
Related
I started to do research to find out why the word "join" is used for the Thread.join() method. In fact, it waits for the thread to end on which it is called and pauses the main thread to wait for it so, there is nothing to join. So, its name should be something like:
Thread.pauseCaller();
Thread.freezeCaller();
Thread.focusThread();
Thread.runBefore();
I found one simple sentence after too much research which says that:
Thread.join(); name comes from the concept of the calling thread waiting until the specified thread joins it.
I am totally unable to get this above sentence into my mind and failed to understand the background context of using the word join for this method. What does the word "join" represent in this context? There is nothing to join anything else; instead, it just pauses the calling thread to wait for the thread followed by the join(). So, can anyone tell the context of using the join word for this method?
The word "join" comes from the ForkâJoin model, where "fork" means to split the thread into multiple threads for parallel processing, and "join" means to wait for the parallel threads to complete their part, before continuing in a single thread.
Join is a common term used in models of concurrency, which implies that two separate independently running threads are synchronising with each other and one thread will not proceed until the other reaches a specific join point. So 2 threads are joining back together into one. In Java, this is usually when the other Thread finishes its task.
Note that this might not be exactly the same in models where the tasks are backed by reusable worker threads, such as when using an ExecutorService to wait for a result, and using CompletableFuture.join() to block until the result is available. In this case the joining is more related to the task executed in parallel than the actual underlying worker thread which might be reused for other tasks afterwards.
The name itself comes from the fork-join model for parallelizing tasks and collecting their results.
and excuse the lack of knowledge on multithreaded apps, but I am new to the field.
Is there a pattern or common used methodology for monitoring the 'job completion' or 'job status' of worker threads from a monitor (a class that acts as a monitor)?
What I have currently done is create a list of workers and create one thread for each worker. After all threads have started i am looping over the worker list and 'checking their status' by making a call to a method.
At that time I couldn't come up with a different solution, but being new to the field, I don't know if this is the way to go, or if there are other solutions or patterns that I should study.
Depending on what you want, there are many ways that you can do this.
If you just want to wait until all the threads finish (i.e. all you care about is having everything finish before moving on), you can use Thread.join():
try {
for (Thread t: threadsIWaitOn)
t.join();
} catch (InterruptedException iex) {
/* ... handle error ...
}
If you want a more fine-grained control over the thread status and want to be able, at any time, to know what threads are doing, you can use the Thread.getState() function. This returns a Thread.State object that describes whether the thread is running, blocked, new, etc., and the Javadoc specifically says that it's designed for monitoring the state of a thread rather than trying to synchronize on it. This might be want you want to do.
If you want even more information than that - say, how to get a progress indicator for each thread that counts up from 0 to 100 as the thread progresses - then another option might be to create a Map from Threads to AtomicIntegers associating each thread with a counter, then pass the AtomicInteger into the constructor of each thread. That way, each thread can continuously increment the counters, and you can have another thread that continuously polls the progress.
In short, you have a lot of options based on what it is that you're trying to accomplish. Hopefully something in here helps out!
Use a ThreadPool and Executor, then you get a Future<> and you can poll for their completion and some more nice stuff, too. I can appreciate this book for you: Java Concurrency in Practice
Try to use any kind of synchronization. For example, wait on some kind of monitor/semaphore until job is done / whatever you need.
I am trying to synchronize a pair of non-UI threads, one thread to run game logic and one thread to render, in order to execute tasks in a logical and efficient order. A constraint I imposed myself was that the entire system operate at an allocation-free steady state, so all display objects are returned and 'recycled' and therefore the two threads must maintain a sort of two-way dialog, which occurs when I call the 'swapBuffers()' method.
In pseudocode, the order of events in the game thread looks something like this:
while(condition)
{
processUserInput();
runGameLogicCycle(set number of times);
waitForBuffersSwapped();
unloadRecycleBuffer(); //This function modifies one buffer
loadDisplayBuffer(); ///This function modifies another buffer
waitForRenderFinished();
renderThread.postTask(swapBuffersAndRender);
}
The render thread is chosen to do the task of swapping buffers such that the game logic thread can do tasks in the meantime that do not modify the buffers. In my code, I combine the task of swapping buffers and rendering and define it as a Runnable object which is posted to the render thread's handler. In pseudocode, that runnable looks something like this:
{
//Swap the buffers
}
gameThread.notifyThatBuffersSwapped();
{
//Render items to screen
}
gameThread.notifyThatItemsRendered();
My problem is an implementation problem. I am familiar with the concepts of handlers, synchronization blocks, and ReentrantLocks. I am aware of the Lock.await() Lock.signal() methods, but I find the documentation insufficient when trying to understand how they behave when called in an iterating loop.
How does one implement ReentrantLocks to make two threads wait on each other in such a way? Please include a practical idiom in your answer if possible.
I'm not sure a Lock is what you want. You do want the current thread to have exclusive access to the objects, but once you release the lock you want to be sure the other thread gets to execute before you get the lock again.
You could, for example, use the poorly-named ConditionVariable:
loop:
game thread: does stuff w/objects
game thread: cv1.close()
game thread: cv2.open()
[render thread now "owns" the objects]
game thread: does stuff w/o objects
game thread: cv1.block()
game thread: [blocks]
loop:
render thread: does stuff w/objects
render thread: cv2.close()
render thread: cv1.open()
[game thread now "owns" the objects]
render thread: cv2.block()
render thread: [blocks]
This operates the two threads in lockstep. You get some concurrency when doing operations on non-shared objects, but that's it.
java.util.concurrent provides CountDownLatch, but that's a one-shot object, which goes against your desire to avoid allocations. The fancy CyclicBarrier does more.
This isn't a great solution -- while locks weren't exactly what you wanted, they were part of what you wanted, and I've done away with them here. It's not possible to look at the code and easily determine that both threads can't operate on the objects simultaneously.
You may want to consider double-buffering the objects. You'd need twice as much memory, but the synchronization issues are simpler: each thread essentially has its own set of data to work on, and the only time you have to pause is when the game thread wants to swap sets. Concurrency is maximized. If the game thread is late, the render thread just draws what it has again (if you're using a GLSurfaceView) or skips rendering. (You can get fancy and triple-buffer the whole thing to improve throughput, but that increases memory usage and latency.)
I have the following situation. I have an application that runs mostly on one thread. It has grown large, so I would like to run a watchdog thread that gets called whenever the main thread changes into a different block of code / method / class so I can see there is "movement" in the code. If the watchdog gets called by the same area for more than a second or a few, it shall set a volatile boolean that the main thread reads at the next checkpoint and terminate / restart.
Now the problem is getting either of the threads to run somewhat at the same time. As soon as the main thread is running, it will not let the watchdog timer count properly. I was therefore thinking of yielding every time it calls the watchdog (so it could calculate time passed and set the value) but to no avail. Using Thread.sleep(1) instead of Thread.yield() works. But I don't want to have several areas of code just wasting calculation time, I am sure I am not doing it the way it is meant to be used.
Here a very simple example of how I would use Thread.yield(). I do not understand why the Threads here will not switch (they do, after a "long" and largely unpredictable time). Please give me an advice on how to make this simple example output ONE and TWO after each other. Like written before, if I switch yield() with sleep(1), it will work just like I'd need it to (in spite of waiting senselessly).
Runnable run1 = new Runnable(){
public void run(){
while(true){
System.out.println("ONE");
Thread.yield();
}
}
};
Runnable run2 = new Runnable(){
public void run(){
while(true){
System.out.println("TWO");
Thread.yield();
}
}
};
Thread tr1 = new Thread(run1);
Thread tr2 = new Thread(run2);
tr1.start();
tr2.start();
Thread.yield()
This static method is essentially used to notify the system that the
current thread is willing to "give up the CPU" for a while. The
general idea is that:
The thread scheduler will select a different thread to run instead of
the current one.
However, the details of how yielding is implemented by the thread
scheduler differ from platform to platform. In general, you shouldn't
rely on it behaving in a particular way. Things that differ include:
when, after yielding, the thread will get an opportunity to run again;
whether or not the thread foregoes its remaining quantum.
The take away is this behavior is pretty much optional and not guaranteed to actually do anything deterministically.
What you are trying to do is serialize the output of two threads in your example and synchronize the output in your stated problem ( which is a different problem ), and that will require some sort of lock or mutex to block the second thread until the first thread is done, which kind of defeats the point of concurrency which is usually the reason threads are used.
Solution
What you really want is a shared piece of data for a flag status that the second thread can react to the first thread changing. Preferably and event driven message passing pattern would be even easier to implement in a concurrently safe manner.
The second thread would be spawned by the first thread and a method called on it to increment the counter for which block it is in, you would just use pure message passing and pass in a state flag Enum or some other notification of a state change.
What you don't want to do is do any kind of polling. Make it event driven and just have the second thread running always and checking the state of its instance variable that gets set by the parent thread.
I do not understand why the Threads here will not switch (they do, after a "long" and largely unpredictable time). Please give me an advice on how to make this simple example output ONE and TWO after each other. Like written before, if I switch yield() with sleep(1), it will work just like I'd need it to (in spite of waiting senselessly).
I think this is more about the difference between ~1000 println calls in a second (when you use sleep(1)) and many, many more without the sleep. I think the Thread is actually yielding but it may be that it is on a multiple processor box so the yield is effectively a no-op.
So what you are seeing is purely a race condition high volume blast to System.out. If you ran this for a minute with the results going to a file I think you'd see a similar number of "ONE" and "TWO" messages in the output. Even if you removed the yield() you would see this behavior.
I just ran a quick trial with your code sending the output to /tmp/x. The program with yield() ran for 5 seconds, generated 1.9m/483k lines, with the output sort | uniq -c of:
243152 ONE
240409 TWO
This means that each thread is generating upwards of 40,000 lines/second. Then I removed the yield() statements and I got just about the same results with different counts of lines like you'd expect with the race conditions -- but the same order of magnitude.
I have 2 threads T1 and T2 ,both have different jobs so usually we prefer to accomplish this task by thread Joins.
But we can do this with out using join(). We can add T2 thread's code inside T1 thread.
What difference does this make ?
Joining a thread means that one waits for the other to end, so that you can safely access its result or continue after both have finished their jobs.
Example: if you start a new thread in the main thread and both do some work, you'd join the main thread on the newly created one, causing the main thread to wait for the second thread to finish. Thus you can do some work in parallel until you reach the join.
If you split a job into two parts which are executed by different threads you may get a performance improvement, if
the threads can run independently, i.e. if they don't rely on each other's data, otherwise you'd have to synchronize which costs performance
the JVM is able to execute multiple threads in parallel, i.e. you have a hyperthreading/multicore machine and the JVM utilizes that
usually we prefer to accomplish this task by thread Joins.
No we don't. We accomplish this task by starting two threads. There is no obligation to use join() so there is no 'should' about it. If you want to pause the current thread while another thread completes, do so. If you don't, don't.
If you call T1.join(); from T2 it will wait for T1 to die (finish). It is a form of thread synchronization, but from what you describe you can simply fire of two thread and simply do not use join. If you use two threads then the work will be done in parallel, if you put the code only in one thread then the work will be done sequentially.
Here is the reason to use join: You use it when final result depends on result of two tasks which could run at the same time.
Example1:
After user clicks submit button the program has to call two external webservices to update their respective systems. It can be done at the same time that is why we would create a separate thread for one of webservices.
The user will sit before the screen and wait for a notification: Your submission is OK! The screen should say OK only after both threads finished.
Two things.
Join is used only when one thread must wait for the open to finish (lets say thread A prepares a file and thread B cannot continue until the file is ready). There are instance where threads are independent and no join is needed (for example most of daemon threads).
With threading you get several things:
- mainly, independence in the order of execution. Lets say that you have a program that when you push a button does some heavy processing. If you do that processing in the main thread, you GUI will freeze until the task is finished. If you do the processing in another thread, then the GUI thread is "freed" and the GUI keeps working.
- in some (most) of modern computers, creating several threads could allow the OS to use the different cores to serve different threads, improving performance.
The drawback is bigger complexity, as you need information of other threads execution state.
You could use something like a java.util.concurrent.CountDownLatch, eg:
CountDownLatch doneSignal = new CountDownLatch(2);
and have each thread countDown() when they're done, so a main thread knows when both threads have completed.
using Join also like we can add the T2 thread's code inside T1 thread
join() like the method name implies waits for the thread to die and joins it at the end of execution. You can add one thread's code inside another but that would destroy the purpose of using 2 separate threads to run your jobs concurrently. Placing one code after the other would run your statements in sequence. There is no concurrency.
When in doubt, consult the javadocs - http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.html#join%28%29
If T1 and T2 do different tasks which do not depend on state changes caused by each other - you should not join them to reap advantages of parallel execution. In case there are state dependenices you should synchronize both threads using mechanisms like wait/notify or even .Join() depending on your use case.
And as for, combining the run() methods of both threads, it's entirely left to you. I mean, you should understand why both threads are of different "types" (as they have different run() body) in the first place . It's a design aspect and not a performance aspect.
All the parallel threads typically needs to join at some point in the code thereby allowing them to wait until all threads terminate. After this point typically the serial processing continues. This ensures proper synchronisation between peer threads so that subsequent serial code does not begin abruptly before all parallel threads complete the collective activity.
The main difference is when we join T2 thread with T1 ,the time T2 is executing the job can be utilised by T1 also ,that means they will do different job parllely.But this cann't happen when you include the T2 thread code inside T1 thread.