2

I have a consumer thread blocking on removing from a queue. There are going to be periods during which I know nothing will be added to the queue.

My question is: is it worth adding the complexity of managing when to start/stop the thread, or should I just leave it waiting until queue starts getting elements again?

mkvcvc
  • 1,515
  • 1
  • 18
  • 41

3 Answers3

4

If the concurrent queue implementation that you're using is worth it's salt then the thread will not be busy-waiting for very long. Some implementations may do this briefly for performance reasons but after that then it will block and will not be consuming CPU cycles. Therefore the difference between a stopped thread and a blocked thread becomes more or less meaningless.

Use a concurrent queue. See Which concurrent Queue implementation should I use in Java?

Michael
  • 41,989
  • 11
  • 82
  • 128
  • No related but great : "If one of my answers helped you, feel free to donate" with the perfect link ! And to think that some are not ironic... – davidxxx Nov 08 '18 at 09:12
  • BTW Most queue implementations do busy wait for a short time, e.g. 1000 attempts before backing off, to yielding or waiting. This means when the process is very active you get the performance close to busy waiting. context switching can be more expensive than busy waiting for a short time. – Peter Lawrey Nov 08 '18 at 09:55
  • @PeterLawrey Thanks Peter. I did quickly try to fact-check myself, but couldn't find any decent descriptions of the implementation details. I've edited my answer – Michael Nov 08 '18 at 10:10
0

When dealing with Multithreading its a best practice to just act when you have a performance problem. Otherwise I would just leave it like it is to avoid trouble.

BullshitPingu
  • 79
  • 2
  • 6
0

I dont think there is a big impact on the performance since the thread is blocked (inactive waiting). It could make sense if the thread is holding expensive resources which can be released for that time. I would keep this as simple as possible, especially in a concurrent enviroment complexity can lead to strange errors.

Meini
  • 77
  • 3
  • 19