0

The following scneario is what i was thinking of:
- 2 Threads, 1 Producer, 1 Consumer
- T1 creates the Queue and starts the next thread, and is repsonsible for puting elements into the queue

ServerThread implements Runnable{

    run(){
        BlockingQueue q = new ArrayBlockingQueue(1024);
        ListenerThread lt = new ListenerThread8(q);
        lt.start();

        ....

        q.put(message);

    }
}

-T2 will wait for elements in the queue and handles them

ListenerThread implements Runnable{
        ...
        run(){
            while(run){
               if(!q.isEmpty){
                    sendMessage(q.getfirst());
               }else{
                    sleep(1000);
               }
            }
        }
   }

This is just a pseudo implementation of how i want to implement my part of the program.
-Could this work?
-And could this work with the static modifier on the queue?

Gobliins
  • 3,848
  • 16
  • 67
  • 122
  • 1
    May be you should try? – Andremoniy Mar 12 '15 at 08:49
  • @Andremoniy When talking about multi-threading, trying is really not enough (though it is needed), due to [heisenbugs](http://en.wikipedia.org/wiki/Heisenbug), and theoretical analysis is needed. – amit Mar 12 '15 at 08:51
  • It is better to use Concurrent Queue it is Thread Safe – VenkatKrishna Mar 12 '15 at 08:52
  • You need to make sure you either used `synchronized` blocks or else use concurrent data structures when reading/writing from the queue. – npinti Mar 12 '15 at 08:53
  • @Andremoniy I am unexperienced in multithreading and read an article from jenkov, so i like to get some knowledge from advanced users before starting right of. I have a bit limited testing slack at my current environment – Gobliins Mar 12 '15 at 08:55
  • @npinti - [BlockingQueue implementations are thread-safe](http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/BlockingQueue.html) – OldCurmudgeon Mar 12 '15 at 13:59

1 Answers1

2

This is the natural pattern for producer-consumer so yes this will work.

By the way - you don't need to check the queue to see if it is empty - you just need to call take which will wait until something is there.

class Thing {
}

class ServerThread implements Runnable {

    @Override
    public void run() {
        BlockingQueue<Thing> q = new ArrayBlockingQueue<>(1024);
        ListenerThread lt = new ListenerThread(q);
        new Thread(lt).start();

        q.put(message);

    }
}

class ListenerThread implements Runnable {

    volatile boolean run;
    private final BlockingQueue<Thing> q;

    public ListenerThread (BlockingQueue<Thing> q) {
        this.q = q;
    }

    @Override
    public void run() {
        while (run) {
            try {
                sendMessage(q.take());
            } catch (InterruptedException ex) {
                run = false;
            }
        }
    }
}

You should not need to make the queue static.

The only adjustment I would recommend would be to not create the listener inside the server run method. The server should know as little as possible about the consumer. The queue, the server and the consumer should all be created and linked up someplace else.

OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
  • You _can't_ make a queue `static`. @Gobliins, There is no such thing as a `static` queue. You can have a `static` _variable_ that references a queue, but that has no effect whatsoever on how the queue behaves when it is accessed by different threads. – Solomon Slow Mar 12 '15 at 13:53
  • @jameslarge Yes, the thing i was looking for seems to be InheritableThreadLocal – Gobliins Mar 12 '15 at 14:17
  • @Gobliins - Are you sure you need an `InheritableThreadLocal` - they are used in [very obscure](http://www.javalobby.org/java/forums/t54279.html) circumstances. – OldCurmudgeon Mar 12 '15 at 14:49
  • @OldCurmudgeon The problem was, i need a static variable but this variable should only be accesible in two referenced threads. With threadLocal i had only a copy of this variable but not the reference to the same variable at all. – Gobliins Mar 16 '15 at 09:36