ansaurus

Question

Answer 1

+1 A:

Normally the compiler should not make such harmful optimizations. If you're still unsure, you could use the volatile keyword to prevent optimizations on that id variables.

Kosi2801 2010-01-22 18:25:23

volatile doesn't prevent all relevant optimizations. It prevents the value from being cached in a register, but pretty much nothing else. Reads/writes can still be reordered.

jalf 2010-01-22 18:37:03

A good treatment of when to use volatile, as part of the Linux kernel documentation: http://www.mjmwired.net/kernel/Documentation/volatile-considered-harmful.txt

asveikau 2010-01-22 18:37:57

@jalf: but do compilers really reorder reads/writes so that they cross function-call-boundaries? Assignments and function calls mixed together are quite common and I guess there would be a lot of problems all over the place if the assigment of variables could switch order with function calls.

Kosi2801 2010-01-24 10:58:57

@Kosi2801: A compiler might do that (imagine if it inlines the function call), but only if it determines that it is safe to do so. But the compiler doesn't, and can't, take threading into account when performing that analysis. It preserves the semantics within one thread of execution, but it can and will reorder reads/writes that may affect other threads. And even if the compiler doesn't, the CPU itself does the same thing. The *only* way to ensure ordering of reads/writes is with a memory barrier. Both the compiler and CPU respects those.

jalf 2010-01-24 14:35:10

Thanks for the more in-depth explanation, it's more clear now for me :)

Kosi2801 2010-01-25 11:54:32

Answer 2

+4 A:

It is possible to compile with O3!

The compiler will never optimize across a function call unless the function is marked as pure using function-attributes.

The mutex functions aren't pure, so it's absolutely safe to use them with O3.

Nils Pipenbrinck 2010-01-22 18:33:40

You mean "unless the function is marked as pure **or the compiler is able to determine that it is safe to do so**. Of course, the end result is the same, the compiler won't make an optimization in general, unless it can verify that it is safe.

jalf 2010-01-22 18:38:06

If `current_id` and `shared_id` are both local variables which have not escaped the current scope (address hasn't been given to anybody else, etc.) then the optimizer could well reorder those line disregarding possible mutation from the external function calls. I assume that's not the case here, though.

ephemient 2010-01-22 19:15:36

@ephemient: but if they are local and no one on the outside knows of them how could an external function call modify them?

Kosi2801 2010-01-24 11:00:40

@Kosi801: Perhaps through buffer overruns of some other data on the stack or other illegal memory accesses. It's unportable and wrong, but I've seen people try `int a, b; foo(

ephemient 2010-01-24 18:10:03

ansaurus

tags:

views:

answers:

Statement reordering with locks

related questions