0

Besides wait/notify is there a cleaner way of notification of events among threads?
E.g. if I want Thread X to notify ThreadY that something occured is there a better construct in concurrent package than build this on top of wait/notify?
My requirements are simple: ThreadB expects an event to happen. ThreadA is responsible to detect such changes. When a change happens ThreadA informs ThreadB

Update:
I need to do Observer/Observable pattern but I want the observable to block as little as possible when it notifies the observers over the loop.
I.e. the observers would be separate threads and the observable on fire change would "notify" them so as to block as little as possible

Jim
  • 18,826
  • 34
  • 135
  • 254
  • 1
    Can you give more details about your requirements? What have you looked at in `java.util.concurrent` (e.g. `CyclicBarrier`, `CountdownLatch`? Do you need to pass information, or just the notification itself? – Jon Skeet Feb 26 '13 at 13:25
  • Better how? java has semaphores, IIRC. – Martin James Feb 26 '13 at 13:25
  • @JonSkeet:Please see update.Those constructs you mention are about starting threads together etc right? – Jim Feb 26 '13 at 13:28
  • @MartinJames:I mean if there is a construct in higher level than wait/notify I would like to use that – Jim Feb 26 '13 at 13:29
  • 1
    Nothing better than wait/notify for this. Just do it. Simple. – xagyg Feb 26 '13 at 13:46
  • there is nothing wrong in using wait/notify in your scenario. – cybye Feb 26 '13 at 13:47

6 Answers6

0

Don't write with wait/notify. Use java.concurrent utils. http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/package-summary.html

As example if unbound queue is suitable for your requirements then use ConcurrentLinkedQueue: http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html

BTW Best option is to avoid manually managing of threads at all by using futures and actors instead.

Andriy Plokhotnyuk
  • 7,883
  • 2
  • 44
  • 68
0

You can use ExecutorService.It is extended from Executor which provides methods to manage termination and methods that can produce a Future for tracking progress of one or more asynchronous tasks.It is a very simple for using in a situation like you described Inter Thread Communication.

Dangling Piyush
  • 3,658
  • 8
  • 37
  • 52
  • @Jim If i got you correct you are talking about this design http://en.wikipedia.org/wiki/Observer_pattern – Dangling Piyush Feb 26 '13 at 13:43
  • That's right.But I need the notification to be done in a separate thread so that the observable is not blocked.Just notify and return back – Jim Feb 26 '13 at 13:47
0

You still are vague in your requirements unfortunately. There are three main concurrent primitives you can use for notification at a higherlevel then wait/notify & await/signal.

You can have a barrier that waits for threads to complete, a barrier that waits for a message from another thread or you can have a barrier that waits a number of threads on an event.

For the furst you can use a CyclicBarrier, CountdownLatch or Phaser.

For the second you can use any BlockingQueue whether LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue or TransferQueue.

And for the last you can use an ExecutorService + Future.

Next question:

What exactly is an event and what is changing? That is important, if a field is changing you can back your field/event update with a SettableFuture

Edit:

Can you include a new library. It appears Akka would work nicely for you.

John Vint
  • 39,695
  • 7
  • 78
  • 108
  • The second you write:`a barrier that waits for a message from another thread` seems exactly what I need.But how is a queue used?I don't need a queue here.Also I am not sure what else to write to be clearer – Jim Feb 26 '13 at 13:43
  • @Jim when you say `update to notify` does the notified thread need a result from the updating thread, or does it just need to be notified that it can start something. – John Vint Feb 26 '13 at 14:52
0

java.util.concurrent.locks package classes Lock, Condition and others give more control over thread coordination.

Evgeniy Dorofeev
  • 133,369
  • 30
  • 199
  • 275
0

If you don't want to block your observers (because they are busy with other tasks), then you need to implement some sort of polling mechanism. You cannot just magically call a method in another thread that is not blocked because that other thread has its own sequential logic.

The simplest polling solution would be to set a volatile variable to a special value and check periodically that variable from the observer threads.

lbalazscs
  • 17,474
  • 7
  • 42
  • 50
0

if you don't want to introduce any complex data structure and just notify threads then you can also look at interrupting threads. Consumer threads and run in loop and when interrupted they peforming processing and then exit / run in loop again.

Amrish Pandey
  • 800
  • 1
  • 7
  • 11