lkml.org 
[lkml]   [2014]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 0/5] arch: atomic rework
From
Date
On Sun, 2014-02-09 at 17:24 -0800, Linus Torvalds wrote:
> On Sun, Feb 9, 2014 at 5:16 PM, Torvald Riegel <triegel@redhat.com> wrote:
> >
> > (a) seems to say that you don't like requiring programmers to mark
> > atomic accesses specially. Is that the case?
>
> In Paul's example, they were marked specially.
>
> And you seemed to argue that Paul's example could possibly return
> anything but 0/0.

Just read my reply to Paul again. Here's an excerpt:

> Initial state: x == y == 0
>
> T1: r1 = atomic_load_explicit(x, memory_order_relaxed);
> atomic_store_explicit(42, y, memory_order_relaxed);
> if (r1 != 42)
> atomic_store_explicit(r1, y, memory_order_relaxed);
>
> T2: r2 = atomic_load_explicit(y, memory_order_relaxed);
> atomic_store_explicit(r2, x, memory_order_relaxed);

Intuitively, this is wrong because this let's the program take a step
the abstract machine wouldn't do. This is different to the sequential
code that Peter posted because it uses atomics, and thus one can't
easily assume that the difference is not observable.


IOW, I wrote that such a compiler transformation would be wrong in my
opinion. Thus, it should *not* return 42.
If you still see how what I wrote could be misunderstood, please let me
know because I really don't see it.

Yes, I don't do so by swearing or calling other insane, and I try to see
the reasoning that those compilers' authors might have had, even if I
don't agree with it. In my personal opinion, that's a good thing.

> If you really think that, I hope to God that you have nothing to do
> with the C standard or any actual compiler I ever use.
>
> Because such a standard or compiler would be shit. It's sadly not too uncommon.

Thanks for the kind words. Perhaps writing that was quicker than
reading what I actually wrote.




\
 
 \ /
  Last update: 2014-02-10 03:21    [W:1.321 / U:1.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site