Re: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion

["Paul E. McKenney" <paulmck@kernel.org>]

On Thu, Nov 09, 2023 at 10:24:23AM -0800, Boqun Feng wrote:
> On Thu, Nov 09, 2023 at 05:25:05PM +0100, Jonas Oberhauser wrote:
> [...]
> > > 4.	Semantics of volatile.	Perhaps the current state is the best
> > > 	that can be hoped for, but given that the current state is a
> > > 	few vague words in the standard in combination with the fact
> > > 	that C-language device drivers must be able to use volatile
> > > 	to reliably and concurrently access memory shared with device
> > > 	firmware, one would hope for better.
> > 
> > 
> > Is it really so bad? I think the definition in the manual is quite precise,
> > if confusing. (volatiles are visible side effects and must therefore have
> > the same program order in the abstract machine and in the implementation,
> > and that's pretty much it).
> 
> But I don't think there is any mention on whether current volatile
> accesses can be excluded from data race, or whether a volatile access
> on a machine-word size natually aligned object can be teared or not.

Here is my understanding:  It must be possible to write C-language
device drivers for devices that...

1.	read and write to normal memory.  If this device has C-langugae
	firmware, volatile reads and writes involving aligned
	machine-word-sized locations must not invoke undefined behavior.

2.	allow concurrent reads and writes to MMIO registers (or to
	normal memory).  Even ignoring the device firmware, volatile
	reads and writes involving aligned machine-word-sized locations
	must not invoke undefined behavior.

Not necessarily a popular view, but then again, in my experience,
objective reality never has been trying to win a popularity contest.

							Thanx, Paul

> Regards,
> Boqun
> 
> > There should just be a large explanatory note about what it implies and what
> > it doesn't imply.
> > 
> >