Tom, 

Actually you right. I get it! 

Gil, 
thanks for your note. You obviously right. If I use multithreaded executor 
I got a lot races in a result. 
So, does it mean that my both version of example are correct? 

How to interpret a citation given by Cezary?: "If x and y are actions of 
the same thread and x comes before y in program order, then hb(x, y)."
For my eye the key is in interpreting of program order. So, if we have two 
statements [X, Y] and order of execution does not matter because both are 
intrathread-consistent it means that [Y,X] are in program order and HB(Y,X) 
by a rule I cite above. 

So, If we had no Executor's (and no other) guarantee it could be reordered. 


W dniu środa, 26 września 2018 04:49:21 UTC+2 użytkownik Gil Tene napisał:
>
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to