User: Password:
|
|
Subscribe / Log in / New account

ACCESS_ONCE()

ACCESS_ONCE()

Posted Aug 7, 2012 19:42 UTC (Tue) by daglwn (guest, #65432)
In reply to: ACCESS_ONCE() by dgm
Parent article: ACCESS_ONCE()

Oh, we have plenty of cases where we try to cater to users who stretch (to put it mildly) the standard. But one must recognize that the programmer is no longer programming in said language. He or she is programming in some other, ill-defined language.

My point is that a bug caused by the programmer not adhering to the language standards is not caused by the compiler. The compiler team may be willing to work around the problem but that doesn't mean the code ain't broke.

> If something has the potential of doing harm, and the user is perfectly
> capable of doing it by hand anyway if really needed, then it's best for
> the compiler not to do it.

The problem is that the compiler has *no way* to know if the code is potentially harmful because the code is doing something outside the definition of the language. The problem ACCESS_ONCE is trying to solve is a perfect example. The compiler doesn't know which parts of code will be operating in a multi-threaded environment, much less which pieces of memory are shared. We have "volatile" to mark variables in a way that happens to work for our current threading models. But it is the only thing we have in C right now.

Compiler writers generally don't want to limit legal transformations because those transformations can help the vast majority of programmers who don't have whatever specialized problem one programmer might complain about.


(Log in to post comments)

ACCESS_ONCE()

Posted Aug 8, 2012 14:30 UTC (Wed) by dgm (subscriber, #49227) [Link]

> The problem is that the compiler has *no way* to know if the code is potentially harmful

It's not the code that it's harmful, but the transformation the compiler does in the optimization. To put it another way: the compiler chooses to do something that is NOT what the code says. It does so because it assumes it's safe. Because there's no way it can be sure if the transformation is safe (or not!), it should not be doing it.

> The compiler doesn't know which parts of code will be operating in a multi-threaded environment

Isn't it common sense that any code compiled today _can_ be used in a multi-threaded environment?

ACCESS_ONCE()

Posted Aug 8, 2012 16:56 UTC (Wed) by daglwn (guest, #65432) [Link]

> It's not the code that it's harmful, but the transformation the compiler
> does in the optimization.

No. The code is the specification of what the programmer wants to happen. If the programmer doesn't mark something "volatile" when it should be, there's no way the compiler can automatically infer that information.

> Because there's no way it can be sure if the transformation is safe (or
> not!), it should not be doing it.

You've just killed all compiler optimization.

> Isn't it common sense that any code compiled today _can_ be used in a
> multi-threaded environment?

And any variable might be shared. So now the compiler must assume everything is volatile.

You've just killed all compiler optimization.

ACCESS_ONCE()

Posted Aug 13, 2012 10:07 UTC (Mon) by dgm (subscriber, #49227) [Link]

> And any variable might be shared.

Threads are supposed to share all memory, aren't they?

>You've just killed all compiler optimization.

Only the unsafe ones. There are plenty of opportunities for optimization, but I don't think this is an example of one.

ACCESS_ONCE()

Posted Aug 13, 2012 16:41 UTC (Mon) by daglwn (guest, #65432) [Link]

> Threads are supposed to share all memory, aren't they?

It depends on the threading model and since the standard doesn't specify one, the compiler cannot know in the general case.

Now, gcc has for example the -pthreads switch that tells it something about what to expect so that can help. But the kernel build system almost certainly doesn't use that.

> There are plenty of opportunities for optimization, but I don't think
> this is an example of one.

When one restricts what is know about memory accesses, the compiler kills a *lot* of compiler transformation. Much much more than one would think. Spill code gets a lot more inefficient, for example, which you wouldn't expect to happen since spills are entirely local. But it does because the compiler cannot do certain peeps that can help reduce the amount of spill code.

The "big" transformations like loop restructuring, vectorization and the like are almost impossible if the behavior of memory can't be determined. These are no more "unsafe" than any other transformation. The compiler won't do them if it doesn't know it's safe according to the standard.

ACCESS_ONCE()

Posted Aug 13, 2012 16:58 UTC (Mon) by jwakely (guest, #60262) [Link]

> Now, gcc has for example the -pthreads switch that tells it something about what to expect so that can help.

Except that for many platforms it's equivalent to '-D_REENTRANT -lpthread' and so only affects the preprocessor and linker, which doesn't tell the compiler anything.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds