Re: anole: assorted stability problems - Mailing list pgsql-hackers

From Robert Haas
Subject Re: anole: assorted stability problems
Date
Msg-id CA+Tgmob0X+YXJhQGLpj95i2AMc93QvGf1QV-mkriTgXFqB46YQ@mail.gmail.com
Whole thread Raw
In response to Re: anole: assorted stability problems  (Andres Freund <andres@anarazel.de>)
Responses Re: anole: assorted stability problems  (Andres Freund <andres@anarazel.de>)
Re: anole: assorted stability problems  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
>> On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund <andres@anarazel.de> wrote:
>> > On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
>> >> #define S_UNLOCK(lock)        \
>> >>       do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
>> >
>> > Robert, how did you choose that? Isn't _Asm_sched_fence just a compiler
>> > barrier? Shouldn't this be a _Asm_mf()?
>>
>> The point of the commit was to make spinlocks act as compiler barriers
>> as well as CPU barriers.  So I was just looking to add a compiler
>> barrier to what was already there.
>
> You removed a volatile at the same time, and volatile on IA64 has
> acquire/release semantics.

Can you explain what you mean by volatile having acquire/release
semantics?  I don't see how volatile can create a CPU barrier, but I'm
guessing that it somehow can and that you're about to enlighten me.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Reduce ProcArrayLock contention
Next
From: Andres Freund
Date:
Subject: Re: anole: assorted stability problems