[concurrency-interest] Java ForkJoin demo applications

David Holmes davidcholmes at aapt.net.au
Thu Dec 8 18:25:21 EST 2011


Sorry I can't answer inline with these mixed-mode html messages. :(

Yes any code that wants to be cancellable has to poll the cancellation
state. FJ is nohing special in this regard.

I see what you mean about the daemon state. Tricky. If they are not daemons
then lifecycle management for the FJPool becomes very problematic in real
apps (trivial in toy apps of course).

Cheers,
David
  -----Original Message-----
  From: Dr Heinz M. Kabutz [mailto:heinz at javaspecialists.eu]
  Sent: Friday, 9 December 2011 9:13 AM
  To: dholmes at ieee.org
  Cc: Doug Lea; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] Java ForkJoin demo applications




explained.  The other thread, however, keeps on running forever.

So to be clear this is exactly as expected. There is no synchronization
action between the two tasks that causes a happens-before relationship
between the reads and writes of "running". So in this case "running" must be
a volatile field.
  Yes, it is as I expected.

The daemon threads make this whole exercise a bit deceptive.  Let's say
we do not join() the thread that was forked.  That would probably be a
coding mistake.  But if we did that, then the task would occupy one core
at 100% and there would be no way to cancel it.

What has this got to do with the thread being a daemon ? The daemon state of
a thread only influences when the VM can terminate.

Any thread spinning in a tight infinite loop can not be cancelled as there
are no "cancellation points" in the loop. Your only recourse there would be
to try Thread.stop().
  Right, I'm still trying to figure out how this F/J works best.  This means
that any calculation that takes a while will need to regularly check the
isCanceled() flag.

  What I mean by deceptive is that if you run a toy example from your main()
method, it will terminate by simply killing the daemon threads, even if the
job has not actually finished.  If you then run this in a larger
application, you could end up with a problem.

  I do understand, I think, what's going on, but am just worried about the
9_999_970 "other" Java programmers who are not on this list ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111209/a00c5022/attachment-0001.html>


More information about the Concurrency-interest mailing list