Memory Semantics of CompletableFuture

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Memory Semantics of CompletableFuture

thurstonn
Hello,

I wanted to inquire about the memory visibility semantics/guarantees of
CompletableFuture#runAfterBothAsync
and
CompetableFuture#thenRunAsync

I have a dependency graph that looks like the following:
3 initial tasks (A, B, C) which run independently, then afterwards (looping
through some rows)
C depends on (prior) C and prior B
B depends on (prior) B and prior A
A depends on prior A,

so code looks like (in a loop):
C = C.runAfterBothAsync(B, lambda)
B = B.runAfterBothAsync(A, lambda)
A = A.thenRunAsync(lambda)

the lambdas write to a shared array, but there is no clobbering (a single
write to each cell), my understanding is that each "new" CF, is *guaranteed*
to see the writes of any of its dependencies before it executes.  Surely
that is correct, although CF's javadoc is strangely silent on any memory
guarantees.
Also I'm assuming the MV guarantees extend to the master thread (the one
invoking the above code). i.e. any writes it has made happen before any
reads/writes in the CF's

Anyway, In my tests I get inconsistent results, surely due to some memory
visibility issues; I'm not 100% sure it's not a problem on my end, but I
wanted to get confirmation on what the memory visibility guarantees there
are or are not;


*I could instead, of course, join on all 3 CF's before "submitting" new
ones, creating any new ones in each iteration, but I really like the above
style and prefer not to have the master thread block at all (until all rows
have been processed)



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Memory Semantics of CompletableFuture

Martin Buchholz-3
Are you not expecting the lambdas to run concurrently?

On Mon, Oct 23, 2017 at 1:11 PM, thurstonn <[hidden email]> wrote:
Hello,

I wanted to inquire about the memory visibility semantics/guarantees of
CompletableFuture#runAfterBothAsync
and
CompetableFuture#thenRunAsync

I have a dependency graph that looks like the following:
3 initial tasks (A, B, C) which run independently, then afterwards (looping
through some rows)
C depends on (prior) C and prior B
B depends on (prior) B and prior A
A depends on prior A,

so code looks like (in a loop):
C = C.runAfterBothAsync(B, lambda)
B = B.runAfterBothAsync(A, lambda)
A = A.thenRunAsync(lambda)

the lambdas write to a shared array, but there is no clobbering (a single
write to each cell), my understanding is that each "new" CF, is *guaranteed*
to see the writes of any of its dependencies before it executes.  Surely
that is correct, although CF's javadoc is strangely silent on any memory
guarantees.
Also I'm assuming the MV guarantees extend to the master thread (the one
invoking the above code). i.e. any writes it has made happen before any
reads/writes in the CF's

Anyway, In my tests I get inconsistent results, surely due to some memory
visibility issues; I'm not 100% sure it's not a problem on my end, but I
wanted to get confirmation on what the memory visibility guarantees there
are or are not;


*I could instead, of course, join on all 3 CF's before "submitting" new
ones, creating any new ones in each iteration, but I really like the above
style and prefer not to have the master thread block at all (until all rows
have been processed)



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Memory Semantics of CompletableFuture

thurstonn
I'm not sure I understand; of course A, B, C can run concurrently.

It's just the "new" C, has to wait for the "old" C, and "old" B, etc.
But at most (A, B, C) are running at the same time.

So, e.g. if the initial A fell behind, the new B would wait



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Memory Semantics of CompletableFuture

Martin Buchholz-3
Are you confusing the lambdas with their dependencies (A, B, C)?

Again I ask: Are you not expecting the lambdas to run concurrently?

On Mon, Oct 23, 2017 at 1:33 PM, thurstonn <[hidden email]> wrote:
I'm not sure I understand; of course A, B, C can run concurrently.

It's just the "new" C, has to wait for the "old" C, and "old" B, etc.
But at most (A, B, C) are running at the same time.

So, e.g. if the initial A fell behind, the new B would wait



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Memory Semantics of CompletableFuture

thurstonn
Again, I answer.
I expect the lambdas to run concurrently, and *they do* - this is certain;
the lambdas are the CFs, or to be more precise the CFs are just wrappers
around the lambdas.

I was asking about the memory visibility guarantees of the respective
methods



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Memory Semantics of CompletableFuture

Martin Buchholz-3


On Mon, Oct 23, 2017 at 1:44 PM, thurstonn <[hidden email]> wrote:
Again, I answer.
I expect the lambdas to run concurrently, and *they do* - this is certain;
the lambdas are the CFs, or to be more precise the CFs are just wrappers
around the lambdas.

I was asking about the memory visibility guarantees of the respective
methods


I agree we should say more about memory visibility guarantees.

But common sense suggests that completion/start of dependent actions has the semantics of volatile variable write/read ("total order of synchronization actions")
 

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Memory Semantics of CompletableFuture

thurstonn
I completely agree with that, in fact I would suggest that "common sanity"
demands it;
anyway, the problem turned out to be, not surprisingly, on my end



--
Sent from: http://jsr166-concurrency.10961.n7.nabble.com/
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest