Re: spinlock support on loongarch64

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: 吴亚飞 <wuyf41619(at)hundsun(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: spinlock support on loongarch64
Date: 2022-11-02 18:29:44
Message-ID: 1836682.1667413784@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2022-11-02 11:37:35 -0400, Tom Lane wrote:
>> I wonder if we shouldn't just do that (ie, try to use
>> __sync_lock_test_and_set) as a generic fallback on any unsupported
>> architecture. We could get rid of the separate stanza for RISC-V
>> that way. The main thing that an arch-specific stanza could bring
>> is knowledge of the best data type width to use for a spinlock;
>> but I don't see a big problem with defaulting to "int". We can
>> always add arch-specific stanzas for any machines where that's
>> shown to be a seriously poor choice.

> Yes, please. It might not be perfect for all architectures, and it might not
> be good for some very old architectures. But for anything new it'll be vastly
> better than not having spinlocks at all.

So about like this, then.

regards, tom lane

Attachment Content-Type Size
fall-back-to-__sync_lock_test_and_set-1.patch text/x-diff 2.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-11-02 18:55:04 Re: spinlock support on loongarch64
Previous Message Justin Pryzby 2022-11-02 18:10:17 Re: pg15 inherited stats expressions: cache lookup failed for statistics object