[concurrency-interest] Reusing CompletableFuture

Viktor Klang viktor.klang at gmail.com
Thu Jul 28 15:04:01 EDT 2016


For the CompletableFuture itself: I recommended sharing it as a
CompletionStage instead, since that is not mutable.
For the value of the CompletionStage/CompletableFuture, same rules apply to
most concurrent datastructures: instances made available through it needs
to either be immutable, thread-safe or the usage predictably harmless. :)

On Thu, Jul 28, 2016 at 8:26 PM, Alex Otenko <oleksandr.otenko at gmail.com>
wrote:

> What is? Reusability?
>
> I don’t know about CompletableFuture specifically, but mutability has an
> immense impact on the implementation, since reuse requires knowing that the
> mutator repurposing the structure is the last entity looking at it in the
> old guise. Then there are gotchas that whoever keeps a reference to it,
> must also have a way of knowing which version of the thing it is looking at
> - like, suddenly you are not allowed to pass around CompletableFuture
> uncontrollably, need to devise ways to solve ABA problem - which becomes a
> problem due to mutability.
>
> Alex
>
> On 28 Jul 2016, at 16:17, Viktor Klang <viktor.klang at gmail.com> wrote:
>
> Isn't this a general requirement for concurrency (coordination) structures?
>
> --
> Cheers,
>>
> On Jul 28, 2016 11:57, "Alex Otenko" <oleksandr.otenko at gmail.com> wrote:
>
>> An isolated fact of reuse is also not very meaningful. You need
>> cross-board support for reuse for the bulk of memory/stateful/stateless
>> objects referenced by CompletableFuture.
>>
>> Alex
>>
>> > On 24 Jul 2016, at 19:11, Pavel Rappo <pavel.rappo at gmail.com> wrote:
>> >
>> > Hi Martin,
>> >
>> > Quite a strong statement. I don't think an isolated fact of mutability
>> > of an entity precludes us from reusing this entity (pool of objects?
>> > reusable buffers?).
>> >
>> > You're talking about obtrudeException(Throwable ex) and obtrudeValue(T
>> > value), right? In my example the CF was returned by an API to a user
>> > and this CF was completed prior to be returned.
>> >
>> > On Sun, Jul 24, 2016 at 5:19 PM, Martin Buchholz <martinrb at google.com>
>> wrote:
>> >> Don't reuse CompletableFutures.
>> >> Most obviously because they're mutable.
>> >>
>> >> See also https://bugs.openjdk.java.net/browse/JDK-8161600
>> >>
>> >> On Sun, Jul 24, 2016 at 5:57 AM, Pavel Rappo <pavel.rappo at gmail.com>
>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> Is it generally safe to reuse an instance of CompletableFuture? Or am
>> I
>> >>> risking
>> >>> with memory leaks due to dependants build up?
>> >>>
>> >>> Say, I have a method that returns a CF. In some cases it may return a
>> CF
>> >>> straight away indicating that the action has been already done.
>> Should I
>> >>> always
>> >>> create a new completed CF, or can I reuse a pre-cached one?
>> >>>
>> >>> There's a comment in the class itself, but I'm not sure I understand
>> it
>> >>> enough
>> >>> to make a conclusion:
>> >>>
>> >>>     * ...Without precautions, CompletableFutures would be prone to
>> >>>     * garbage accumulation as chains of Completions build up, each
>> >>>     * pointing back to its sources. So we null out fields as soon as
>> >>>     * possible.  The screening checks needed anyway harmlessly ignore
>> >>>     * null arguments that may have been obtained during races with
>> >>>     * threads nulling out fields.  We also try to unlink non-isLive
>> >>>     * (fired or cancelled) Completions from stacks that might
>> >>>     * otherwise never be popped: Method cleanStack always unlinks non
>> >>>     * isLive completions from the head of stack; others may
>> >>>     * occasionally remain if racing with other cancellations or
>> >>>     * removals...
>> >>>
>> >>> Thanks,
>> >>> -Pavel
>> >>> _______________________________________________
>> >>> 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
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>


-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160728/cd9c5284/attachment-0001.html>


More information about the Concurrency-interest mailing list