Comments on: More fun with Java Concurrency: BlockingQueue

By: Effective using Java Concurrency part-3 « When IE meets SE…

Effective using Java Concurrency part-3 « When IE meets SE… — Mon, 10 Aug 2009 07:46:43 +0000

[...] JDK API 1.2 Java 5’s BlockingQueue 1.3 More fun with Java Concurrency: BlockingQueue 1.4 Which Java blocking queue is most efficient for single-producer single-consumer scenarios 1.5 [...]

By: deadlock

deadlock — Thu, 12 Mar 2009 16:19:00 +0000

Think about the case:
1. parse put the last one to the queue
2. Persister take the last one from the queue
3. Persister go around the while loop, and executing queue.take() again (NOTE, one this time, done=false, and the Persister will wait …)
4. parse set done to true

The persister will wait along. You’d better use a mark Object as the last element in the queue.

By: christian

christian — Thu, 12 Mar 2009 16:03:30 +0000

@Alex: thanks for spotting the > 0 typo… it’s been fixed.

By: Alex

Alex — Thu, 12 Mar 2009 07:56:41 +0000

Agree about volatile boolean done.
Also “if (!entities.isEmpty() > 0)” is not readable code

By: ruben

ruben — Wed, 04 Mar 2009 15:33:59 +0000

Making done volatile will do too.

By: Ben

Ben — Wed, 25 Feb 2009 09:03:07 +0000

The JMM makes no guaranty that the update to “done” will be visible. Due to a race you might block forever waiting for new work.

Executors#callable() wraps a Runnable as a Callable.

By: christian

christian — Wed, 25 Feb 2009 05:52:51 +0000

@Marcin I agree that both threads are interacting with the boolean “done”, I don’t see how an issue might arise over its state. What exactly is the problem you’re seeing?

By: christian

christian — Wed, 25 Feb 2009 05:48:58 +0000

@Nick Look at the API for ExecutorService, it takes Callable (not Runnable). Do you have a workaround?

By: More fun with Java Concurrency: BlockingQueue « Nexsoft’s Blog

More fun with Java Concurrency: BlockingQueue « Nexsoft’s Blog — Tue, 24 Feb 2009 21:45:31 +0000

[...] More fun with Java Concurrency: BlockingQueue Published by christian on February 23, 2009 in Java [...]

By: Nick

Nick — Tue, 24 Feb 2009 20:11:44 +0000

Why to implement Callable if no value is actually calculated and returned?

Why not to use java.util.Iterator instead of Parser (and automatically clean up instead of explicitly exposing the close() method)?

By: Marcin Dabrowski

Marcin Dabrowski — Tue, 24 Feb 2009 19:37:02 +0000

It is very interesting example, but maybe you should consider of using AtomicBoolean as done type to create fully thread safe example.

By: Ben

Ben — Tue, 24 Feb 2009 17:10:48 +0000

I believe that you could have simplified this code by allowing the executor’s internal blocking queue manage the work queue. The parser would submit a batch into the executor, rather than one-by-one, wrapped by the task. That would probably drop the code size down by a third, without losing anything performance-wise.