Re: Inefficient barriers on solaris with sun cc

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Oskari Saarenmaa <os(at)ohmu(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inefficient barriers on solaris with sun cc
Date: 2014-10-06 15:38:47
Message-ID: CA+TgmoZ318tOGf8WGEFixzjf2ZHk3=5O6eiK3+V=m3TKAaQ24A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 2, 2014 at 2:06 PM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-10-06 15:42:08 Re: Inefficient barriers on solaris with sun cc
Previous Message Robert Haas 2014-10-06 15:35:25 Re: UPSERT wiki page, and SQL MERGE syntax