Re: CompletableFuture dependent ordering
Viktor Klang via Concurrency-interest <[email protected]> Tue, 5 Jan 2021 09:17:54 +0000
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <CANPzfU8+SgmvyV+BGBetjR8-rUjDaDEUCDwkApeDq4ySYK7Tog@mail.gmail.com> |
It's similar for Scala Futures—happens-before can only be assumed for chained effects, as "callbacks" registered to the same Future can potentially run in parallel. On Mon, Jan 4, 2021 at 11:31 PM Alex Otenko via Concurrency-interest < [email protected]> wrote: > I think you can only safely assume the happens-before between the > computation of the value consumed and the computation consuming that value. > > That is, dependencies are ordered only through explicit chaining. > CompletionStage doesn't seem to guarantee any other order. > > Alex > > On Mon, 4 Jan 2021, 22:32 Benjamin Manes via Concurrency-interest, < > [email protected]> wrote: > >> Hi everyone, >> >> CompletableFuture maintains a Treiber stack for processing dependents, >> such as "thenAccept" and "whenComplete" actions. I couldn't find a previous >> discussion on this design decision. Can you please educate me on why a LIFO >> stack was preferred over a FIFO queue? >> >> The current behavior seems less intuitive and a lack of awareness can >> cause subtle surprises. While chaining against the dependent can resolve >> these gotchas most of the time, there are scenarios where it is more >> correct to work with the original future instance and to chain dependents >> on the side. This has come up a few times regarding an asynchronous cache >> and while I have educated users on this behavior, a workaround within the >> cache would merely shift the pain by no longer returning the user's >> supplied future instance. While I can understand the stack might have been >> preferred as a more elegant implementation, I do not yet see why it would >> be better by its external behavior. >> >> Thanks and happy new year. >> _______________________________________________ >> Concurrency-interest mailing list >> [email protected] >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest >> > _______________________________________________ > Concurrency-interest mailing list > [email protected] > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > -- Cheers, √ _______________________________________________ Concurrency-interest mailing list [email protected] http://cs.oswego.edu/mailman/listinfo/concurrency-interest