I have a simple multi-threaded program as follows:
I have T1,T2,T3...Tn threads, which all run in parallel.
Each thread has a queue of objects, which I want to add/remove items from.
In every single addition, I'd like to print it to the screen.
public void run() {
while(!queue.isEmpty()) {
Object obj = queue.poll();
System.out.println(obj.toString());
}
}
And for addition, I simply use:
void addObj(Object obj) {
this.queue.add(obj);
}
In the same class of the thread.
I am using addObj across the program, in different times.
The problem when I add objects to the queue, it doesn't seem that run even cares.
In some cases it did print the new object, but in many cases it did not, and it still considered the queue as empty.
How can I make sure that the thread is aware of this item being added?
Should I use any callback?
What is the right approach for such tasks?
I also noticed that when I use Thred.sleep() it helps, but it looks pretty ugly, I guess.
UPDATE: each thread should have it's own thread. I am creating the threads in a separte "thread-manger" which starts them one by one.
Each thread has it's own private queue, which should be filled on the fly.
Items can be add/removed to the queues in any given time, before and after the threads started.
Your run() method finishes immediately if the queue is empty. If you want threads to work event if queues are empty use something like this:
public void run() {
while(true) {
if (!queue.isEmpty()) {
Object obj = queue.poll();
System.out.println(obj.toString());
}
}
}
Here a even prettier solution. Avoids polling ;)
public void run() {
while(true) {
if (!queue.isEmpty()) {
Object obj = queue.poll();
System.out.println(obj.toString());
}
queue.wait();
}
}
and here the code to add:
void addObj(Object obj) {
this.queue.add(obj);
this.queue.notify();
}
"each thread should have it's own thread" could you explain more?
If you mean that the queue belongs to the thread, after doing an add you do a poll and you print what your message.
Related
I have the following method:
void store(SomeObject o) {
}
The idea of this method is to store o to a permanent storage but the function should not block. I.e. I can not/must not do the actual storage in the same thread that called store.
I can not also start a thread and store the object from the other thread because store might be called a "huge" amount of times and I don't want to start spawning threads.
So I options which I don't see how they can work well:
1) Use a thread pool (Executor family)
2) In store store the object in an array list and return. When the array list reaches e.g. 1000 (random number) then start another thread to "flush" the array list to storage. But I would still possibly have the problem of too many threads (thread pool?)
So in both cases the only requirement I have is that I store persistantly the objects in exactly the same order that was passed to store. And using multiple threads mixes things up.
How can this be solved?
How can I ensure:
1) Non blocking store
2) Accurate insertion order
3) I don't care about any storage guarantees. If e.g. something crashes I don't care about losing data e.g. cached in the array list before storing them.
I would use a SingleThreadExecutor and a BlockingQueue.
SingleThreadExecutor as the name sais has one single Thread. Use it to poll from the Queue and persist objects, blocking if empty.
You can add not blocking to the queue in your store method.
EDIT
Actually, you do not even need that extra Queue - JavaDoc of newSingleThreadExecutor sais:
Creates an Executor that uses a single worker thread operating off an unbounded queue. (Note however that if this single thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks.) Tasks are guaranteed to execute sequentially, and no more than one task will be active at any given time. Unlike the otherwise equivalent newFixedThreadPool(1) the returned executor is guaranteed not to be reconfigurable to use additional threads.
So I think it's exactly what you need.
private final ExecutorService persistor = Executors.newSingleThreadExecutor();
public void store( final SomeObject o ){
persistor.submit( new Runnable(){
#Override public void run(){
// your persist-code here.
}
} );
}
The advantage of using a Runnable that has a quasi-endless-loop and using an extra queue would be the possibility to code some "Burst"-functionality. For example you could make it wait to persist only when 10 elements are in queue or the oldest element has been added at least 1 minute ago ...
I suggest using a Chronicle-Queue which is a library I designed.
It allows you to write in the current thread without blocking. It was originally designed for low latency trading systems. For small messages it takes around 300 ns to write a message.
You don't need to use a back ground thread, or a on heap queue and it doesn't wait for the data to be written to disk by default. It also ensures consistent order for all readers. If the program dies at any point after you call finish() the message is not lost. (Unless the OS crashes/loses power) It also supports replication to avoid data loss.
Have one separate thread that gets items from the end of a queue (blocking on an empty queue), and writes them to disk. Your main thread's store() function just adds items to the beginning of the queue.
Here's a rough idea (though I assume there will be cleaner or faster ways for doing this in production code, depending on how fast you need things to be):
import java.util.*;
import java.io.*;
import java.util.concurrent.*;
class ObjectWriter implements Runnable {
private final Object END = new Object();
BlockingQueue<Object> queue = new LinkedBlockingQueue();
public void store(Object o) throws InterruptedException {
queue.put(o);
}
public ObjectWriter() {
new Thread(this).start();
}
public void close() throws InterruptedException {
queue.put(END);
}
public void run() {
while (true) {
try {
Object o = queue.take();
if (o == END) {
// close output file.
return;
}
System.out.println(o.toString()); // serialize as appropriate
} catch (InterruptedException e) {
}
}
}
}
public class Test {
public static void main(String[] args) throws Exception {
ObjectWriter w = new ObjectWriter();
w.store("hello");
w.store("world");
w.close();
}
}
The comments in your question make it sound like you are unfamilier with multi-threading, but it's really not that difficult.
You simply need another thread responsible for writing to the storage which picks items off a queue. - your store function just adds the objects to the in-memory queue and continues on it's way.
Some psuedo-ish code:
final List<SomeObject> queue = new List<SomeObject>();
void store(SomeObject o) {
// add it to the queue - note that modifying o after this will also alter the
// instance in the queue
synchronized(queue) {
queue.add(queue);
queue.notify(); // tell the storage thread there's something in the queue
}
}
void storageThread() {
SomeObject item;
while (notfinished) {
synchronized(queue) {
if (queue.length > 0) {
item = queue.get(0); // get from start to ensure same order
queue.removeAt(0);
} else {
// wait for something
queue.wait();
continue;
}
}
writeToStorage(item);
}
}
I have a queue that contains work items and I want to have multiple threads work in parallel on those items. When a work item is processed it may result in new work items. The problem I have is that I can't find a solution on how to determine if I'm done. The worker looks like that:
public class Worker implements Runnable {
public void run() {
while (true) {
WorkItem item = queue.nextItem();
if (item != null) {
processItem(item);
}
else {
// the queue is empty, but there may still be other workers
// processing items which may result in new work items
// how to determine if the work is completely done?
}
}
}
}
This seems like a pretty simple problem actually but I'm at a loss. What would be the best way to implement that?
thanks
clarification:
The worker threads have to terminate once none of them is processing an item, but as long as at least one of them is still working they have to wait because it may result in new work items.
What about using an ExecutorService which will allow you to wait for all tasks to finish: ExecutorService, how to wait for all tasks to finish
I'd suggest wait/notify calls. In the else case, your worker threads would wait on an object until notified by the queue that there is more work to do. When a worker creates a new item, it adds it to the queue, and the queue calls notify on the object the workers are waiting on. One of them will wake up to consume the new item.
The methods wait, notify, and notifyAll of class Object support an efficient transfer of control from one thread to another. Rather than simply "spinning" (repeatedly locking and unlocking an object to see whether some internal state has changed), which consumes computational effort, a thread can suspend itself using wait until such time as another thread awakens it using notify. This is especially appropriate in situations where threads have a producer-consumer relationship (actively cooperating on a common goal) rather than a mutual exclusion relationship (trying to avoid conflicts while sharing a common resource).
Source: Threads and Locks
I'd look at something higher level than wait/notify. It's very difficult to get right and avoid deadlocks. Have you looked at java.util.concurrent.CompletionService<V>? You could have a simpler manager thread that polls the service and take()s the results, which may or may not contain a new work item.
Using a BlockingQueue containing items to process along with a synchronized set that keeps track of all elements being processed currently:
BlockingQueue<WorkItem> bQueue;
Set<WorkItem> beingProcessed = new Collections.synchronizedSet(new HashMap<WorkItem>());
bQueue.put(workItem);
...
// the following runs over many threads in parallel
while (!(bQueue.isEmpty() && beingProcessed.isEmpty())) {
WorkItem currentItem = bQueue.poll(50L, TimeUnit.MILLISECONDS); // null for empty queue
if (currentItem != null) {
beingProcessed.add(currentItem);
processItem(currentItem); // possibly bQueue.add(newItem) is called from processItem
beingProcessed.remove(currentItem);
}
}
EDIT: as #Hovercraft Full Of Eels suggested, an ExecutorService is probably what you should really use. You can add new tasks as you go along. You can semi-busy wait for termination of all tasks at regular interval with executorService.awaitTermination(time, timeUnits) and kill all your threads after that.
Here's the beginnings of a queue to solve your problem. bascially, you need to track new work and in process work.
public class WorkQueue<T> {
private final List<T> _newWork = new LinkedList<T>();
private int _inProcessWork;
public synchronized void addWork(T work) {
_newWork.add(work);
notifyAll();
}
public synchronized T startWork() throws InterruptedException {
while(_newWork.isEmpty() && (_inProcessWork > 0)) {
wait();
if(!_newWork.isEmpty()) {
_inProcessWork++;
return _newWork.remove(0);
}
}
// everything is done
return null;
}
public synchronized void finishWork() {
_inProcessWork--;
if((_inProcessWork == 0) && _newWork.isEmpty()) {
notifyAll();
}
}
}
your workers will look roughly like:
public class Worker {
private final WorkQueue<T> _queue;
public void run() {
T work = null;
while((work = _queue.startWork()) != null) {
try {
// do work here...
} finally {
_queue.finishWork();
}
}
}
}
the one trick is that you need to add the first work item _before you start any workers (otherwise they will all immediately exit).
Right now I'm torn up in deciding the best way of handling request objects that I send up to a server. In other words, I have tracking request objects for things such as impression and click tracking within my app. Simple requests with very low payloads. There are places in my app where said objects that need to be tracked appear concurrently next to each other (at most three concurrent objects that I have to track), so every time said objects are visible for example, I have to create a tracking request object for each of them.
Now I already know that I can easily create a singleton queue thread which adds those objects into a vector and my thread either processes them in the main loop or calls wait on the queue until we have objects to process. While this sounds like a clear cut solution, the queue can accumulate into the dozens, which can be cumbersome at times, since it's making one connection for each request, thus it won't run concurrently.
What I had in mind was to create a thread pool which would allow me to create up two concurrent connections via semaphore and process thread objects that would contain my tracking event requests. In other words, I wanted to create a function that would create a new thread Object and add it into a Vector, in which the thread pool would iterate through the set of threads and process them two at a time. I know I can create a function that would add objects like so:
public boolean addThread(Runnable r){
synchronized(_queue){
while(!dead){
_queue.addElement(r);
//TODO: How would I notify my thread pool object to iterate through the list to process the queue? Do I call notify on the queue object, but that would only work on a thread right??
return true
}
return false;
}
What I am wondering is how will the threads themselves get executed. How can I write a function that would execute the thread pool after adding a thread to the list? Also, since the semaphore will block after the second connection, will that lock up my app until there is an open slot, or will it just lock up in the thread pool object while looping through the list?
As always, since I am targeting a J2ME/Blackberry environment, only pre-1.5 answers will be accepted, so no Generics or any class from the Concurrent package.
EDIT: So I take it that this is what it should look like more or less:
class MyThreadPool extends Thread{
private final Vector _queue = new Vector();
private CappedSemaphore _sem;
public MyWaitingThread (){
_sem = new CappedSemaphore(2);
this.start();
}
public void run(){
while(!dead){
Runnable r = null;
synchronized(_queue){
if(_queue.isEmpty()){
_queue.wait();
} else {
r = _queue.elementAt(0);
_queue.removeElement(0);
}
}
if(r != null){
_sem.take();
r.run();
_sem.release();
}
}
}
public boolean addThread(Runnable r){
synchronized(_queue){
if(!dead){
_queue.addElement(r);
_queue.notifyAll();
return true
}
return false;
}
}
What you would want to do, in on the thread side have the each thread wait on the queue. For example
class MyWaitingThread extends Thread{
private final Queue _queue;
public MyWaitingThread (Queue _queue){
this._queue = _queue;
}
public void run(){
while(true){
Runnable r = null;
synchronized(_queue){
if(_queue.isEmpty())
_queue.wait();
else
r = queue.pop();
}
if(r != null) r.run();
}
}
}
And in your other logic it would look like:
public void addThread(Runnable r){
if(!dead){
synchronized(_queue){
_queue.addElement(r);
_queue.notifyAll();
}
}
}
That _queue.notifyAll will wake up all threads waiting on the _queue instance. Also, notice I moved the while(!dead) outside of the synchronized block and changed it to if(!dead). I can imagine keeping it the way you originally had it wouldnt have worked exactly like you hoped.
I am trying to program a game in which I have a Table class and each person sitting at the table is a separate thread. The game involves the people passing tokens around and then stopping when the party chime sounds.
how do i program the run() method so that once I start the person threads, they do not die and are alive until the end of the game
One solution that I tried was having a while (true) {} loop in the run() method but that increases my CPU utilization to around 60-70 percent. Is there a better method?
While yes, you need a loop (while is only one way, but it is simplest) you also need to put something inside the loop that waits for things to happen and responds to them. You're aiming to have something like this pseudocode:
loop {
event = WaitForEvent();
RespondToEvent(event);
} until done;
OK, that's the view from 40,000 feet (where everything looks like ants!) but it's still the core of what you want. Oh, and you also need something to fire off the first event that starts the game, obviously.
So, the key then becomes the definition of WaitForEvent(). The classic there is to use a queue to hold the events, and to make blocking reads from the queue so that things wait until something else puts an event in the queue. This is really a Concurrency-101 data-structure, but an ArrayBlockingQueue is already defined correctly and so is what I'd use in my first implementation. You'll probably want to hide its use inside a subclass of Thread, perhaps like this:
public abstract class EventHandlingThread<Event> extends Thread {
private ArrayBlockingQueue<Event> queue = new ArrayBlockingQueue<Event>();
private boolean done;
protected abstract void respondToEvent(Event event);
public final void postEvent(Event event) throws InterruptedException {
queue.put(event);
}
protected final void done() {
done = true;
}
public final void run() {
try {
while (!done) {
respondToEvent(queue.take());
}
} catch (InterruptedException e) {
// Maybe log this, maybe not...
} catch (RuntimeException e) {
// Probably should log this!
}
}
}
Subclass that for each of your tasks and you should be able to get going nicely. The postEvent() method is called by other threads to send messages in, and you call done() on yourself when you've decided enough is enough. You should also make sure that you've always got some event that can be sent in which terminates things so that you can quit the game…
I would look into Locks and Conditions. This way you can write code that waits for a certain condition to happen. This won't take a lot of CPU power and is even much more efficient and better performing than sleeping .
To make a thread run for an infinite time:
final Object obj = new Object();
try {
Thread th = new Thread(new Runnable() {
public void run() {
synchronized(obj) {
try {
System.out.println("Waiting");
obj.wait();
System.out.println("Done waiting");
}catch(Exception ex) {
ex.printStackTrace();
}
}
}
});
th.start();
System.out.println("Waiting to join.");
// Dont notify; but wait for joining. This will ensure that main thread is running always.
th.join();
System.out.println("End of the Program");
} catch(Exception ex) {
ex.printStackTrace();
}
You may add Thread.sleep() with appropriate time to minimize useless loop iterations.
Another solution is using synchronization. While threads are not required to do anything, they enter into a sleeping state on a monitor using the wait() method, and then when the turn comes, required thread is woken up by the notify() method.
Actor model seems suitable for this scenario. Each person sitting on the table and the table itself can be modelled as actors and the event of passing the tokens and starting and stopping of the game can be modelled as messages to be passed between the actors.
As a bonus, by modelling the scenario as actors you get rid of explicit manipulation of threads, synchronization and locking.
On JVM I will prefer using Scala for modelling actors. For Java you can use libraries like Kilim. See this post for a comparison of Actor model related libraries in Java.
One Way is to use while loop but keep a check i.e
while(true){
if(condition!=true){
Thread.sleep(time);
}else{
break;
}
}
This way if your condition says game is not over it will keep person thread at sleep and memory consumption will be very low.
You should test for a condition in the while loop:
while (!gameOver)
{
do_intersting_stuff();
}
Heavy CPU load is typical for busy wait. Is your loop actually just checking a flag over and over, like
while (!gameOver)
{
if (actionNeeded)
{
do_something();
}
}
you might change to another notification system to sleep and wake up, as this just burns CPU time for nothing.
I would like to have a SynchronousQueue where I insert elements from one thread with put(), so the input is blocked until the element is taken in another thread.
In the other thread I perform lots of calculations and from time to time want to check if an element is already available, and consume it. But it seems that isEmpty() always returns true, even if another thread is waiting at the put() call.
How on earth is this possible? Here is the sample code:
#Test
public void testQueue() throws InterruptedException {
final BlockingQueue<Integer> queue = new SynchronousQueue<Integer>();
Thread t = new Thread(new Runnable() {
#Override
public void run() {
while (true) {
if (!queue.isEmpty()) {
try {
queue.take();
System.out.println("taken!");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
// do useful computations here (busy wait)
}
}
});
t.start();
queue.put(1234);
// this point is never reached!
System.out.println("hello");
}
EDIT: Neither isEmpty() nor peek() work, one has to use poll(). Thanks!
From http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/SynchronousQueue.html#put(E) :
isEmpty
public boolean isEmpty()
Always returns true. A SynchronousQueue has no internal capacity.
(haven't looked into this in great detail, but you might want to take a look at either poll or take instead)
In addition to Tim's answer - you are doing nothing in the consumer thread but continuously calling isEmpty() in a tight loop. Rather than asking the OS to not run it until there is something useful for it to do, the consumer thread is continuously busy. Even if isEmpty worked correctly, the producer thread would rarely get a chance to run.
You could (if isEmpty() did work, or you switched to using poll()) make the consumer sleep for a bit between tests when the queue is empty to give the producer a chance to run, or (preferably) just take out the isEmpty() test and let the thread block on the mutex inside the take() in a sensible manner instead of polling.
your code looks like you are trying to do a poll. why not just call the poll() method?