Re: [PATCH] Add support for TAS/S_UNLOCK for aarch64

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Salter <msalter(at)redhat(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Raiskup <praiskup(at)redhat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Add support for TAS/S_UNLOCK for aarch64
Date: 2013-06-04 18:27:59
Message-ID: 29866.1370370479@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Salter <msalter(at)redhat(dot)com> writes:
> On Tue, 2013-06-04 at 13:40 -0400, Tom Lane wrote:
>> We got no response to the question of whether it couldn't be merged with
>> the existing ARM32 code block. I'd prefer not to have essentially
>> duplicate sections in s_lock.h if it's not necessary.

> Of course it could be. I don't think it should be. Aarch64 is a
> completely new architecture with faint resemblance to 32bit arm.

OK, fair enough.

> I went
> back and read the previous thread concerning the problems with builtin
> gcc atomics with certain tool/hardware combinations. Would it be okay to
> add a default implementation based on gcc builtins to be used if no
> arch-specific definitions exist? If so, I could work up a patch for
> review.

We had pretty much rejected that concept in the previous discussion,
I thought. In the first place, there is no good reason to assume
that somebody on a nonstandard platform is using gcc, and in the second,
our review of the available info suggested that the implementation
quality of gcc's builtins is ... um ... variable. Blindly falling back
to that on a platform we haven't tested does not seem very safe.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2013-06-04 18:50:44 RFC: ExecNodeExtender
Previous Message Josh Berkus 2013-06-04 18:23:24 Re: Configurable location for extension .control files