5

I need to wake up or send to sleep a single Thread sometimes, and I'm wondering what is the best and most efficient way to do it.

The first solution is signaling combined with wait-notify (I know how to implement this pattern properly, that's not the question).

I read it somewhere that using the java.concurrent library and CountDownLatch for signaling is more efficient. I checked concurrent.locks.Condition as well, but this topic states that it's merely a (programmer-wise) more safe and generalized construct, without a performance benefit compared to notify/notifyAll. Peter Lawrey recommends using the Concurrency library instead of notify-notifyAll in this comment, so now I'm confused what is the best practice to use.

A related question: which is better performance-wise, notify or notifyAll in my case (i.e. if I have one thread)? I know there are lot of similar threads about this, but none of them give a clear answer. In my case, functionally, it doesn't matter which I use, but I wonder which is faster, then.

Community
  • 1
  • 1
Thomas Calc
  • 2,994
  • 3
  • 30
  • 56
  • I would half-blindly trust Peter Lawrey's suggestions, almost always. – Eugene Aug 23 '12 at 10:59
  • I would only do so if the logical arguments (pro, contra) are balanced or if the problem is empirical and cannot be analytically approached. – Thomas Calc Aug 23 '12 at 12:29

2 Answers2

3

IMO they don't make much difference "performance-wise" since they all suspend the thread calling the corresponding wait so most likely the underlying mechanisms are very similar. And why would performance matter so much anyway? Unless you have some extremely fast wait/signal pattern in which the signal comes immediately after the wait, making a context-switch too expensive and requiring perhaps a spinlock instead, there's no need to worry about performance.

You should implement what you think is the most convenient method programming-wise and then benchmark and see if you really need something more performant.

Tudor
  • 61,523
  • 12
  • 102
  • 142
  • I would go with notify/notifyAll then, but one question remains: for signaling one Thread, which is more efficient? This would require knowing how the JVM is implemented for them. I know the difference is negligible, but preferring one to the other requires no plus optimization work (because I either write "notify" or "notifyall"), so I would like to use the "theoretically" better solution (since there is no reason not to do so). – Thomas Calc Aug 23 '12 at 12:32
  • @Thomas Calc: How often do you expect to use these mechanisms in you app? – Tudor Aug 23 '12 at 12:33
  • It depends on the user input, to be general. In worst case, once per second. – Thomas Calc Aug 23 '12 at 12:34
  • 2
    @Thomas Calc: I was browsing over the source codes but it's hard to tell which is more efficient from there because it eventually jumps into native methods. You'll just have to search for a benchmark of these mechanisms or do one yourself. However, even at one signal/second I still maintain that the difference won't matter. – Tudor Aug 23 '12 at 12:49
  • 1
    If there is any difference, it certainly is sub-millisecond so if it happens once per second, there clearly is no point worrying about it. – assylias Aug 26 '12 at 14:30
0

wait-notify is perfectly fine.

since there's only one thread on the waiting list, there's no difference, semantics or performance wise, between notify and notifyAll.

irreputable
  • 44,725
  • 9
  • 65
  • 93