Re: pgsql: Do all accesses to shared buffer headers through
От | Tom Lane |
---|---|
Тема | Re: pgsql: Do all accesses to shared buffer headers through |
Дата | |
Msg-id | 4966.1129157669@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Do all accesses to shared buffer headers (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: pgsql: Do all accesses to shared buffer headers
|
Список | pgsql-committers |
Neil Conway <neilc@samurai.com> writes: > On Wed, 2005-12-10 at 13:45 -0300, Tom Lane wrote: >> Do all accesses to shared buffer headers through volatile-qualified >> pointers, to ensure that compilers won't rearrange accesses to occur >> while we're not holding the buffer header spinlock. > That is fairly error prone :-( Would it be possible to hide this in a > typedef? How would a typedef make it safer? I see no particular difference between omitting the "volatile" and choosing the wrong typedef. Neither will happen if you follow the coding style of surrounding routines (which is one reason I chose to make *all* the bufmgr routines declare BufferDesc pointers as volatile, even though some of them arguably didn't need to). If you don't follow the coding style, neither convention will catch you at it. We do however have here a New Coding Rule that's good for all parts of the backend: if you are accessing a spinlock-protected data structure then you should be using a volatile-qualified pointer for it. I had at one time thought that volatile-qualifying the spinlock pointer should be enough, on the grounds that compilers shouldn't move other stores across a store to volatile. But apparently gcc only promises not to rearrange volatile stores with respect to each other. regards, tom lane
В списке pgsql-committers по дате отправления: