Re: Should pointers to PGPROC be volatile-qualified?

Поиск
Список
Период
Сортировка
От Brian Hurt
Тема Re: Should pointers to PGPROC be volatile-qualified?
Дата
Msg-id 46DEFDE6.205@janestcapital.com
обсуждение исходный текст
Ответ на Should pointers to PGPROC be volatile-qualified?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Should pointers to PGPROC be volatile-qualified?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Florian G. Pflug"
Дата:
Сообщение: Re: loose ends in lazy-XID-assigment patch
Следующее
От: Tom Lane
Дата:
Сообщение: Re: loose ends in lazy-XID-assigment patch