Re: Should pointers to PGPROC be volatile-qualified?

Tom Lane wrote:

>Comments? Does anyone think the C standard forbids what I'm worried
>about?
>
>

My understanding of the C spec is that it explicitly *allows* for
exactly what you're afraid of. It's even possible if the uses include
function calls, as the compiler might inline the function calls.

The downside of litering the code with volatile qualifications is that
it's an optimization stopper. For example, if proc is declared
volatile, the compiler couldn't merge multiple different proc->foo
references into a single load into a register.

Note that all sorts of weirdnesses are possible when you have shared
mutable state between multiple different threads. For example, assume
you have two threads, and two global ints x and y, initially both 0.
Thread 1 do:
y = 1;
r1 = x;
(where r1 is a local variable in thread 1), while thread 2 does:
x = 1;
r2 = y;
(with r2 being a local variable in thread 2).

Here's the thing: both r1 and r2 can end up 0! I've seen this in real
code. What happens is that the compiler notices that in both cases, the
load and stores are independent, so it can reorder them. And as loads
tend to be expensive, and nothing can progress until the load completes,
it moves the loads up before the stores, assuming the program won't
notice. Unfortunately, it does, as "the impossible" can then happen.

Brian