Re: Should pointers to PGPROC be volatile-qualified? - Mailing list pgsql-hackers

From Brian Hurt
Subject Re: Should pointers to PGPROC be volatile-qualified?
Date
Msg-id 46DEFDE6.205@janestcapital.com
Whole thread Raw
In response to Should pointers to PGPROC be volatile-qualified?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should pointers to PGPROC be volatile-qualified?
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: Re: loose ends in lazy-XID-assigment patch
Next
From: Tom Lane
Date:
Subject: Re: loose ends in lazy-XID-assigment patch