Re: CompletableFuture dependent ordering
Alex Otenko via Concurrency-interest <[email protected]> Mon, 4 Jan 2021 23:28:38 +0000
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <CANkgWKhuTO_aVufv=PiOzuT4u-FPoc0oqojB8yXSTA5Fy1dkjA@mail.gmail.com> |
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