Re: locked reads for atomics

From: John Morris <john(dot)morris(at)crunchydata(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: locked reads for atomics
Date: 2023-11-10 21:49:06
Message-ID: BYAPR13MB2677D57E440A3A94C6D4E3C8A0AEA@BYAPR13MB2677.namprd13.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>I wonder if it's worth providing a set of "locked read" functions.

Most out-of-order machines include “read acquire” and “write release” which are pretty close to what you’re suggesting. With the current routines, we only have “read relaxed” and “write relaxed”. I think implementing acquire/release semantics is a very good idea,

I would also like to clarify the properties of atomics. One very important question: Are atomics also volatile? If so, the compiler has very limited ability to move them around. If not, it is difficult to tell when or where they will take place unless the surrounding code is peppered with barriers.

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-11-10 22:05:48 Re: pgsql: Don't trust unvalidated xl_tot_len.
Previous Message Christoph Berg 2023-11-10 21:42:26 Re: pgsql: Don't trust unvalidated xl_tot_len.