Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have a scenario where I have to call multiple objects concurrently, and each object will call multiple other class's objects internally. After the execution of all child objects, it should return result back to parent object and finally, parent objects will return result back to Main thread. It is basically two level multi threading. I do not know what I should take under consideration when implementing this scenario. I would really appreciate any and all guidance, preferably with some sample code.
I have attached a picture which gives a clear understanding of the scenario.
simplty i need to creatre a set of threads and each created threads have to create another set of threads . and also reqires controll over every thread at any time. hope its clear thanks again
ForkJoinPool and RecursiveTask are designed for such use cases. See fork-join tag
From what I understand: Every parent spawns some amount of children and has to wait for all children (and children of children and so on) to complete?
In that case, each parent can spawn one thread per child and then use a semaphore to wait for all of them to finish. Semaphores allow you to wait for multiple threads at a time.
EDIT: You mention four tasks.
ADD thread: Create a new thread, manage all threads in a list of their parent. Use synchronization to maintain that list because if there is no guarantee that only a single thread will ever touch this list.
PAUSE: Set PAUSED flag. That will cause the thread to sleep() or to wait().
RESUME: Unset PAUSED flag. If PAUSE makes thread wait(), call notify() to wake it up.
DELETE: Set STOPPED flag, then remove from list, or wait until thread finishes before removing from list (depends on what you need). If thread might be PAUSED, make sure, to RESUME it first.
The flags must be used by the thread which is running a loop to determine: Whether to PAUSE and whether to opt out of the loop, thus STOPPING the thread. Something like this:
while (!isStopped)
{
while (hasWork() && !isPaused && !isStopped)
{
// do work
}
if (!isStopped)
{
// either just sleep for a few milliseconds (easy way) or wait()
}
}
Make sure that you don't spawn too many threads. You should rather let children wait than creating even more threads, if you already spawned more than x threads, where x depends on your OS and JVM. Play around with it. Intuition might tell you: The more threads the better, but that is absolutely false. Once you surpass a certain amount of threads, they are already using all your computer's available resources (such as CPU, memory bandwidth and hard-disk bandwidth). Spawning more threads than necessary to use all the resources will just add management overhead and slow down execution.
On modern systems, competing thread scheduling might be done well, but each thread still has it's price tag. Imagine, all threads want to access CPU, memory etc. at the same time. That creates contention and requires a very smart scheduler (smart enough to predict the future and who can do that?) to not cause any noticeable overhead.
Good luck.
you can create the N parent Threads on the main object and after calling start on each thread object you can call a join on each object. The main object will block on the first one waiting for it to finish, once it has finished it will try to join the second, the third, and so on until the Nth, but they probably will already have finished and then the main will be able to finish.
Use the same approach in the relationship between parent and child. However it is not clear from your question what the child threads will have to do, you may need to provide some concurrency control among them depending on the task at hand.
Cheers.
Related
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.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I have finished a GUI app. I have four classes: Main, UserWindow, Task1, Task2. Main class contains a boolean variable buttonStartPressed. Main method starts an instance of the UserWindow class, and waits until the user presses the Start button. As user presses the Start button ( in the UserWindow) the ActionListener assigns true to the static boolean buttonStartPressed and the Main method continues.
Main.java
public static void ......
static boolean buttonStartPressed = false;
...........
while (!buttonStartPress) {
Thread.sleep(50);
}
Task1 t1 = new Task1();
.....
}
}
It works fine, however I do not like the while loop. I feel that this is not the conventional way to write an application. There is another way: i could combine Main and UserWindow classes, and the result of the ActionListener (buttonPressed) would be the start of the Task1. But, on the other hand, I think that Main class and UserWindow classes should be separate from each other.
Yeah, that's wrong. You shouldn't have busy loops....anywhere.
Do you even need the buttonStartPressed variable? Why would you be interested in knowing if it has been pressed, isn't the main idea to perform some action when the button is pressed?
You should create the Task1 in your actionPerformed() method, and depending on what you're trying to do, start a thread that'll perform the task (or just run it in the EDT if it's really fast to do, so it won't freeze the GUI).
Swing (and almost every GUI toolkit) has a dedicated thread. This thread, the Event Dispatch Thread, is started when you first need it. This is generally when you setVisible a JFrame. This thread is a giant loop, whose role is to consume input events and repaint events and to run some logic accordingly.
In your case, you actually have two threads. The first is the main thread and the second is the EDT. Your main thread is doing a busy wait. The code of your actionListener is executed in the EDT as soon as the user presses the button.
You are using a boolean variable as a way to make your two threads communicate. Using some shared memory is indeed one possible way of doing inter-thread communication.
Now, as you suspected you should avoid doing busy waits. It uselessly consumes CPU time, it disturbs the other threads each time it wakes up, and it has an inevitable reaction delay.
Communicating using shared memory is generally bad, too. It is a too low-level way of communicating, and it is often done wrong. Access to a piece of data from two threads must be protected by a locking mechanism. Even a data as simple as a boolean can bite you, as there is no guarantee that if one thread writes to it, the other one will see the modification. In your example, the boolean should be at least declared volatile to have this guarantee.
So, adding the volatile keyword, your solution works : you have an EDT who is happily doing its stuff, and when the user clicks the button, the main thread executes Task1. The first question to ask yourself is : is Task1 a time-consuming task ? Indeed, the simplest solution would be to run Task1 in the EDT, by calling it from actionListener. Be warned that executing some code in the EDT freezes the GUI. If Task1 lasts for less than 100ms, the user won't even notice the freeze, and there is no point in executing it in another thread. If you are worried about coupling your GUI class with your "task" class, then you should just use the observer pattern to prevent a direct dependency.
If the task is time-consuming and you don't want your GUI to freeze, then you should use multiple threads. One solution is the one you implemented. It is somewhat limited, because you only have one main thread, but it works. Your problem now is to make those threads communicate. A really common pattern in inter-thread communication is to use a blocking queue. This is also a shared piece of data, but it is designed to be used by multiple threads. One thread (EDT) writes to it (add()), and the other reads from it (take()) and blocks until something has been written. This may seem overkill for your simple example, but it is a very convenient way of sharing data between threads. The objects written to the blocking queue can be anything ; for example they can represent commands to execute.
A more conventional way of executing a time-consuming function from the GUI is to create or use a dedicated thread when you need to. This can be done using low-level APIs (Thread) or using higher level ones (ExecutorService), both being quite easy to use. Again, use the observer pattern if you want to decouple the GUI action from the thread creation.
I apologize if this wall of text does not offer a simple answer to your question, but there are many things to consider when we mix GUI and threads. I hope it will be useful for you, to understand what your other options are.
while(!anotherThread.isDone());
or
while(!anotherThread.isDone())
Thread.sleep(5);
If you really need to wait for a thread to complete, use
anotherThread.join()
(You may want to consider specifying a timeout in the join call.)
You definitely shouldn't tight-loop like your first snippet does... and sleeping for 5ms is barely better.
If you can't use join (e.g. you're waiting for a task to complete rather than a whole thread) you should look at the java.util.concurrent package - chances are there's something which will meet your needs.
IMHO, avoid using such logic altogether. Instead, perhaps implement some sort of notification system using property change listeners.
As others have said, it's better to just use join in this case. However, I'd like to generalize your question and ask the following:
In general when a thread is waiting for an event that depends on another thread to occur is it better to:
Use a blocking mechanism (i.e. join, conditional variable, etc.) or
Busy spin without sleep or
Busy spin with sleep?
Now let's see what are the implications for each case:
In this case, using a blocking call will effectively take your thread off the CPU and not schedule it again until the expected event occurs. Good for resource utilization (the thread would waste CPU cycles otherwise), but not very efficient if the event may occur very frequently and at small intervals (i.e. a context switch is much more time-consuming than the time it takes for the event to occur). Generally good when the event will occur eventually, but you don't know how soon.
In case two, you are busy spinning, meaning that you are actively using the CPU without performing useful work. This is the opposite of case 1: it is useful when the event is expected to occur very very soon, but otherwise may occupy the CPU unnecessarily.
This case is a sort of trade-off. You are busy spinning, but at the same time allowing other threads to run by giving up the CPU. This is generally employed when you don't want to saturate the CPU, but the event is expected to occur soon and you want to be sure that you will still be there in almost real time to catch it when it occurs.
I would recommend utilizing the wait/notify mechanism that is built into all Java objects (or using the new Lock code in Java 5).
Thread 1 (waiting for Thread2)
while(!thread2.isDone()) {
synchronize(thread2.lockObject) {
thread2.lockObject.wait();
}
}
Thread 2
// finish work, set isDone=true, notify T1
thread2.lockObject.notify();
'lockObject' is just a plain (Object lockObject = new Object()) -- all Java objects support the wait/notify calls.
After that last call to notify(), Thread1 will wake up, hit the top of the while, see that T2 is now done, and continue execution.
You should account for interrupt exceptions and the like, but using wait/notify is hugely helpful for scenarios like this.
If you use your existing code, with or without sleep, you are burning a huge number of cycles doing nothing... and that's never good.
ADDENDUM
I see a lot of comments saying to use join - if the executing thread you are waiting on will complete, then yes, use join. If you have two parallel threads that run at all times (e.g. a producer thread and a consumer) and they don't "complete", they just run in lock-step with each other, then you can use the wait/notify paradigm I provided above.
The second one.
Better though is to use the join() method of a thread to block the current thread until it is complete :).
EDIT:
I just realised that this only addresses the question as it applies to the two examples you gave, not the question in general (how to wait for a boolean value to be changed by another Thread, not necessarily for the other Thread to actually finish).
To answer the question in general I would suggest that rather than using the methods you described, to do something like this I would recommend using the guarding block pattern as described here. This way, the waiting thread doesn't have to keep checking the condition itself and can just wait to be notified of the change. Hope this helps!
Have you considered: anotherThread.join() ? That will cause the current one to be 'parked' without any overhead until the other one terminates.
The second is better than the first, but neither is very good. You should use anotherThread.join() (or anotherThread.join(timeout)).
Neither, use join() instead:
anotherThread.join();
// anotherThread has finished executing.
I have a multi-threaded application which creates hundreds of threads on the fly. When the JVM has less memory available than necessary to create the next Thread, it's unable to create more threads. Every thread lives for 1-3 minutes. Is there a way, if I create a thread and don't start it, the application can be made to automatically start it when it has resources, and otherwise wait until existing threads die?
You're responsible for checking your available memory before allocating more resources, if you're running close to your limit. One way to do this is to use the MemoryUsage class, or use one of:
Runtime.getRuntime().totalMemory()
Runtime.getRuntime().freeMemory()
...to see how much memory is available. To figure out how much is used, of course, you just subtract total from free. Then, in your app, simply set a MAX_MEMORY_USAGE value that, when your app has used that amount or more memory, it stops creating more threads until the amount of used memory has dropped back below this threshold. This way you're always running with the maximum number of threads, and not exceeding memory available.
Finally, instead of trying to create threads without starting them (because once you've created the Thread object, you're already taking up the memory), simply do one of the following:
Keep a queue of things that need to be done, and create a new thread for those things as memory becomes available
Use a "thread pool", let's say a max of 128 threads, as all your "workers". When a worker thread is done with a job, it simply checks the pending work queue to see if anything is waiting to be done, and if so, it removes that job from the queue and starts work.
I ran into a similar issue recently and I used the NotifyingBlockingThreadPoolExecutor solution described at this site:
http://today.java.net/pub/a/today/2008/10/23/creating-a-notifying-blocking-thread-pool-executor.html
The basic idea is that this NotifyingBlockingThreadPoolExecutor will execute tasks in parallel like the ThreadPoolExecutor, but if you try to add a task and there are no threads available, it will wait. It allowed me to keep the code with the simple "create all the tasks I need as soon as I need them" approach while avoiding huge overhead of waiting tasks instantiated all at once.
It's unclear from your question, but if you're using straight threads instead of Executors and Runnables, you should be learning about java.util.concurrent package and using that instead: http://docs.oracle.com/javase/tutorial/essential/concurrency/executors.html
Just write code to do exactly what you want. Your question describes a recipe for a solution, just implement that recipe. Also, you should give serious thought to re-architecting. You only need a thread for things you want to do concurrently and you can't usefully do hundreds of things concurrently.
This is an alternative, lower level solution Then the above mentioed NotifyingBlocking executor - it is probably not as ideal but will be simple to implement
If you want alot of threads on standby, then you ultimately need a mechanism for them to know when its okay to "come to life". This sounds like a case for semaphores.
Make sure that each thread allocates no unnecessary memory before it starts working. Then implement as follows :
1) create n threads on startup of the application, stored in a queue. You can Base this n on the result of Runtime.getMemory(...), rather than hard coding it.
2) also, creat a semaphore with n-k permits. Again, base this onthe amount of memory available.
3) now, have each of n-k threads periodically check if the semaphore has permits, calling Thread.sleep(...) in between checks, for example.
4) if a thread notices a permit, then update the semaphore, and acquire the permit.
If this satisfies your needs, you can go on to manage your threads using a more sophisticated polling or wait/lock mechanism later.