As Tom noted, The Executor's submission happens-before promise prevents a
reordering of (1) and (2) above.
Note that, as written, the reason you you don't have data races between (2)
and (2) is that executor is known to be a single threaded executor (and
will only run one task at a time). Without that quality, you would have
plenty of (2) vs. (2) races. It is not that "doers contain different
objects": your code submits executions of functions using the same x member
of xs to all doers, and it is only the guaranteed serialization in your
chosen executor implementation that prevents x,f()s from racing on the same
x...
On Tuesday, September 25, 2018 at 8:52:14 AM UTC-7, John Hening wrote:
>
> public class Test {
> ArrayList<X> xs;
> ArrayList<Doer> doers;
> Executor executor = Executors.newSingleThreadExecutor();
>
> static class Doer {
> public void does(X x){
> x.f(); //
> (2)
> }
> }
>
> void test() {
> for(X x : xs){
> x.f(); //
> (1)
>
> for(Doer d : doers) {
> executor.execute(() -> d.does(x));
> }
> }
> }
> }
>
>
>
>
> For my eye, if X.f is not synchronized it is incorrect because of two
> facts (and only that two facts):
>
> 1. Obviously, there is data race between (1) and (2). There are no more
> data races here. (doers contains different objects)
> 2. There is no guarantee that (1) will be executed before (2). Yes?
>
> If X.f would be synchronized that code will be correct because:
> 1. There is no data race.
> 2. There is guarantee that (1) will be executed before (2) because (1) is
> a synchronization action and Executor.execute is also a synchronization
> access (not specifically execute itself)
>
> Yes?
>
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
