From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Andres Freund" <andres(at)anarazel(dot)de> |
Cc: | "Marek Szuba" <marecki(at)gentoo(dot)org>, "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Native spinlock support on RISC-V |
Date: | 2021-08-13 17:37:02 |
Message-ID: | 78751.1628876222@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 Fri, Aug 13, 2021, at 19:25, Tom Lane wrote:
>> I now have looked at the patch, and it seems good as far as it goes,
>> but I wonder whether some effort ought to be expended in
>> src/include/port/atomics/.
> That should automatically pick up the intrinsic. I think we should do the same on modern compilers for spinlocks, but that's a separate discussion I guess.
I was looking at the comment in atomics.h about
* Provide a full fallback of the pg_*_barrier(), pg_atomic**_flag and
* pg_atomic_* APIs for platforms without sufficient spinlock and/or atomics
* support. In the case of spinlock backed atomics the emulation is expected
* to be efficient, although less so than native atomics support.
so it seems like someday we might want to expend some effort on native
atomics. I agree that that day need not be today, though. This patch
seems sufficient until we get to the point of (at least) having some
RISC-V in the buildfarm.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-08-13 17:55:53 | Re: [PATCH] Native spinlock support on RISC-V |
Previous Message | Andres Freund | 2021-08-13 17:29:54 | Re: [PATCH] Native spinlock support on RISC-V |