Re: CompletableFuture#postComplete() can be invoked concurrently?

I think target audience is important. This decides which things need to be
said explicitly, and which can be left to be inferred, supposing the target
audience can formulate the right questions.

Say, in this case knowing what a sufficient condition is for this to be
impossible, makes the proof very mechanical. But knowing what questions to
ask seems to be a prerequisite. (And actually the safety guarantees that I
checked the code for, turned out to be documented)

Alex

On Sun, 23 Aug 2020, 13:41 Doug Lea via Concurrency-interest, <
[email protected]> wrote:

> Thanks to Alex and Martin for pointing out that this case cannot arise. It
> would be great if we could have full mechanical proofs of such things.
> People out there occasionally work on these for j.u.c components, but they
> always lag development by a long time. In the mean time, we should improve
> internal algorithm documentation.
> On 8/23/20 3:09 AM, Alex Otenko via Concurrency-interest wrote:
>
> Besides, first need to show reachability of that state.
>
> So you have src.result set. Concurrent invocations of d.completeThrowable
> vs d.completeValue are possible only if two threads can see different
> src.result or different src.result.ex.
>
> I don't see a path to reach this necessary condition.
>
> Alex
>
> On Sun, 23 Aug 2020, 08:03 Martin Buchholz, <[email protected]> wrote:
>
>>      * Method postComplete is called upon completion unless the target
>>      * is guaranteed not to be observable (i.e., not yet returned or
>>      * linked). Multiple threads can call postComplete, which
>>
>> On Sat, Aug 22, 2020 at 11:53 PM Liu <[email protected]> wrote:
>> >
>> > In my first post, There is the special thread execution order.
>> >
>> > high level outcome is:
>> > two thread will invoke CompletableFuture#postComplete()
>> > on same object concurrently.
>> >
>> > expected outcome:
>> > only one thread can invoke CompletableFuture#postComplete()
>> > on a object.
>> >
>> > like I said, in CompletableFuture.UniApply#tryFire(),
>> > d.completeThrowable(x, r); and dep = null;
>> > are not a atomic operation. The gap between two codes
>> > may cause high level outcome.
>> >
>> > PS:when dep == null, it means current Completion Object
>> > has been done.
>> >
>> > PPS: CompletableFuture#postComplete() seems not design to be
>> > invoked on same object.
>> >
>> >
>>
>
> _______________________________________________
> Concurrency-interest mailing [email protected]://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> 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