| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | "Blake, Geoff" <blakgeof(at)amazon(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add spin_delay() implementation for Arm in s_lock.h |
| Date: | 2022-01-07 03:23:38 |
| Message-ID: | 1275075.1641525818@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:
> These separate shm_mq instances forward messages in a circle,
> "leader"->worker_1->worker_2->...->"leader". So there isn't a single contended
> spinlock, but a bunch of different spinlocks, each with at most two backends
> accessing it?
No; there's just one spinlock. I'm re-purposing the spinlock that
test_shm_mq uses to protect its setup operations (and thereafter
ignores). AFAICS the N+1 shm_mq instances don't internally contain
spinlocks; they all use atomic ops.
(Well, on crappy architectures maybe there's spinlocks underneath
the atomic ops, but I don't think we care about such cases here.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lukas Fittl | 2022-01-07 03:33:28 | Re: [PATCH] Add extra statistics to explain for Nested Loop |
| Previous Message | Andres Freund | 2022-01-07 03:13:42 | Re: Add spin_delay() implementation for Arm in s_lock.h |