Should pointers to PGPROC be volatile-qualified?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Should pointers to PGPROC be volatile-qualified?
Дата
Msg-id 20817.1189017680@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Should pointers to PGPROC be volatile-qualified?  (Brian Hurt <bhurt@janestcapital.com>)
Список pgsql-hackers
There are a bunch of places where we do things like
    PGPROC       *proc = arrayP->procs[index];    /* Fetch xid just once - see GetNewTransactionId */    TransactionId
pxid= proc->xid;
 
    ... use pxid several times ...

In the case where "use pxid" involves a function call, this is probably
safe enough, because the compiler can't assume that the called function
won't access and modify the PGPROC.  However, if "use pxid" is straight
line code, I am suddenly wondering if the C compiler could think it can
get away with loading proc->xid more than once instead of expending a
register on it.  As far as it knows there isn't any way for the value
to change underneath it.

The correct fix for this is probably to make the fetch happen through a
volatile-qualified pointer, eg
    volatile PGPROC *proc = arrayP->procs[index];    /* Fetch xid just once - see GetNewTransactionId */
TransactionIdpxid = proc->xid;
 

I'm wondering how far to go with that.  In the extreme we could try to
make MyProc and all other PGPROC pointers volatile-qualified; is that
overkill?

Or maybe I'm worried over nothing.  I can't recall any bug reports that
seem like they could be tied to such a thing, and given that we can only
set, not clear, MyProc->xid and xmin without exclusive lock, there might
not actually be a bug here.  But it seems a bit risky.

Comments?  Does anyone think the C standard forbids what I'm worried
about?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

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