[concurrency-interest] Upcoming jdk9 j.u.c JEP

Greg Wilkins gregw at webtide.com
Fri Jul 24 00:30:03 EDT 2015


I think the point that you are making is that implementations do have to be
careful about which threads they use when calling back (this is not unique
to this API, but a common problem with all async APIs).

In our jetty work, we've encapsulated the concerns in a base class


Who's prime intention is to stop the infinite recursion that can result
with request() -> onNext() -> request() -> ...  However it also addresses
similar issues of using the thread calling subscribe to perform work and
other callbacks.


On 24 July 2015 at 10:12, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Doug,
> I've again try to understand how the Flow API can be safe and i still do
> not understand.
> Let suppose i want to use the OneShotPublisher with the SampleSubscriber
> described in the overview of the class Flow.
> If you take a look to the fields of the class SampleSubscriber:
> - count is written in onSubscribe which is called by the thread that call
> subscribe() but read in onNext() which is called by a thread of the
> executor service.
> - subscription has the same issue, it is initialized by onSubscribe() and
> read by onNext().
> Maybe it's working because ExecutorService.submit() works like
> Thread.start() but as far as i know, the javadoc of sumit() doesn't specify
> that.
> Moreover, the API expose an issue that are not visible in the current
> snippets of code,
> onError() can be called either by the thread that have called subscribe()
> and the thread that call onNext(), so basically, onError() only works if
> the code of onError() has no side effect, so ex.printStackTrace is fine but
> anything but logging is not.
> I'm sure i'm wrong and there is something subtle that my poor mind doesn't
> understand.
> Rémi
> On 07/23/2015 04:23 PM, Doug Lea wrote:
>> Thanks to people who have tried out the proposed updates for jdk9
>> (modest, compared to previous releases) that have been in place since
>> January -- a few enhancements to CompletableFuture, added class
>> SubmissionPublisher and its interface-holder class Flow, plus misc
>> minor updates. If you haven't, try them out from the usual places:
>>     API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/docs/
>>     jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar
>> (compiled using Java8 javac).
>>     Browsable CVS sources:
>> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/
>> (As usual, the easiest way is to run with -Xbootclasspath/p:jsr166.jar
>> but this will almost surely change under upcoming jdk9 module support.)
>> We've been also working to improve async performance more generally
>> inside implementations. Things seem to be stabilizing without
>> controversy. (There has been continuing discussion of Flow interfaces
>> at http://www.reactive-streams.org/ but nothing that has impacted
>> these APIs.)  So it's time to actually propose them for jdk9 as an
>> openjdk JEP.  Which I plan to do within a few days. If you have any
>> comments or concerns, please let me know!
>> Some notes:
>> * Reactive-stream users may be disappointed that we do not include any
>> net/IO-based Flow.Publisher/Subscriber classes, considering that
>> reactive-streams are mainly motivated by net-based frameworks. The
>> reasons for triaging these out are that (1) IO generally falls outside
>> of java.util.concurrent (2) Most net-based frameworks seem to use
>> custom data representation etc (e.g., JSON) that are even further out
>> of scope.  However class SubmissionPublisher can be used as an adaptor
>> to turn just about any kind of source into a Publisher, so provides a
>> nearly universal way of constructing a good non-custom Publisher even
>> from IO-based sources.  (Also notice that SubmissionPublisher can
>> serve as the basis of other actor-like frameworks, including those
>> turning off back-pressure by calling
>> subscription.request(Long.MAX_VALUE) in onSubscribe).
>> * If you are trying out updates with jdk9 early access,
>> (https://jdk9.java.net/download/) notice that as of b73 last week,
>> it by default uses the G1 collector, which is (currently,
>> but hopefully just transiently) not usually the best choice for
>> high-throughput concurrency. You probably want to use switches
>>  -XX:+UseParallelGC -XX:+UseCondCardMark -XX:-UseBiasedLocking
>> * The implementation updates (some not yet committed) focus on
>> improvements in async contexts (CompletableFutures,
>> SubmissionPublishers, plus other older components).  Symmetric async
>> (where agents may be both producers and consumers) performance is
>> inherently more variable than other cases. ForkJoinPool in particular
>> handles now these better. Updates include (1) pool.submit and
>> task.fork now have identical semantics; (2) "Async" FJP mode is now
>> probabilistically fair; (3) Spare threads cannot accumulate; and (4)
>> Ramp-down is faster on large systems.  (In fact, of the oddities under
>> abuse that Ed Harned enjoys identifying, I think the only remaining
>> one is that we still take a global lock to fill in stack traces for
>> cross-thread exceptions, which can slow things to a crawl if you have
>> tons of them, but is still worthwhile in helping developer track down
>> most problems.)
>> * It is likely that some implementations (and possibly even new
>> classes) will be impacted by VarHandles-related work (mainly by Paul
>> Sandoz), that replaced the syntactically-nicer but too-problematic
>> "Enhanced Volatiles" proposal (still the same JEP
>> http://openjdk.java.net/jeps/193).
>> -Doug
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150724/70efa9b6/attachment-0001.html>

More information about the Concurrency-interest mailing list