Re: locked reads for atomics - Mailing list pgsql-hackers

From John Morris
Subject Re: locked reads for atomics
Date
Msg-id BYAPR13MB2677D57E440A3A94C6D4E3C8A0AEA@BYAPR13MB2677.namprd13.prod.outlook.com
Whole thread Raw
In response to locked reads for atomics  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: locked reads for atomics
Re: locked reads for atomics
List 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.

pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: pgsql: Don't trust unvalidated xl_tot_len.
Next
From: Thomas Munro
Date:
Subject: Re: pgsql: Don't trust unvalidated xl_tot_len.