Re: Inefficient barriers on solaris with sun cc
От | Robert Haas |
---|---|
Тема | Re: Inefficient barriers on solaris with sun cc |
Дата | |
Msg-id | CA+TgmoZ318tOGf8WGEFixzjf2ZHk3=5O6eiK3+V=m3TKAaQ24A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inefficient barriers on solaris with sun cc (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Inefficient barriers on solaris with sun cc
|
Список | pgsql-hackers |
On Thu, Oct 2, 2014 at 2:06 PM, Andres Freund <andres@2ndquadrant.com> wrote: >> Also, I pretty much designed those definitions to match what Linux >> does. And it doesn't require that either, though it says that in most >> cases it will work out that way. > > My point is that that read barriers aren't particularly meaningful > without a defined store order from another thread/process. Without any > form of pairing you don't have that. The writing side could just have > reordered the writes in a way you didn't want them. And the kernel docs > do say "A lack of appropriate pairing is almost certainly an error". But > since read barriers also pair with lock releases operations, that's > normally not a big problem. Agreed, but it's possible to have a read-fence where an atomic operation provides the ordering on the other side, or something like that. > I'm still unsure what you want to show with that example? Me, too. I think we've drifted off in the weeds. Do we know what we need to know to fix $SUBJECT? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: