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.