[concurrency-interest] Reusing CompletableFuture

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


On Thu, Jul 28, 2016 at 9:35 PM, Josh Humphries <jh at squareup.com> wrote:

> Unfortunately -- unless you create a defensive copy or use a custom
> subclass of CompletableFuture -- it is mutable, even as CompletionStage:
>
> stage.toCompletableFuture().obtrudeValue(null);
>

Ouch! Having that method always return a new instance would've been safer,
for sure.
(I always use custom CompletionStages)


>
>
>
> ----
> *Josh Humphries*
> Payments Engineering
> Atlanta, GA  |  678-400-4867
> *Square* (www.squareup.com)
>
> On Thu, Jul 28, 2016 at 3:04 PM, Viktor Klang <viktor.klang at gmail.com>
> wrote:
>
>> 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,
>>>>
>> _______________________________________________
>> 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/7dbab98d/attachment-0001.html>


More information about the Concurrency-interest mailing list