Re: Strange Windows problem, lock_timeout test request
От | Tom Lane |
---|---|
Тема | Re: Strange Windows problem, lock_timeout test request |
Дата | |
Msg-id | 17142.1363911399@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Strange Windows problem, lock_timeout test request (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Strange Windows problem, lock_timeout test request
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Mar 18, 2013 at 10:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Because it's wrong. Removing "volatile" means that the compiler is >> permitted to optimize away stores (and fetches!) on the basis of their >> being unnecessary according to straight-line analysis of the code. >> Write barriers don't fix that, they only say that stores that the >> compiler chooses to issue at all have to be ordered a certain way. > I don't think this is correct. The read and write barriers as > implemented are designed to function as compiler barriers also, just > as they do in the Linux kernel and every other piece of software I've > found that implements anything remotely like this, with the lone > exception of PostgreSQL. In PostgreSQL, spinlock acquisition and > release are defined as CPU barriers but not a compiler barrier, and > this necessitates extensive use of volatile all over the code base > which would be unnecessary if we did this the way it's done in Linux > and elsewhere. I think you're just as mistaken as Zoltan. Barriers enforce ordering of operations, not whether an operation occurs at all. regards, tom lane
В списке pgsql-hackers по дате отправления: