On Fri, Aug 04, 2023 at 12:17:58PM -0400, Joel Fernandes wrote: > [...] > > > >> However, the kernel consider the volatile access to be atomic, right? > > > > > > > > The compiler must therefore act as if a volatile access to an aligned > > > > machine-word size location is atomic. To see this, consider accesses > > > > to memory that is shared by a device driver and that device's firmware, > > > > both of which are written in either C or C++. > > > > > > Btw it appears TSAN complaints bitterly on even volatile 4 byte data races. > > > Hence we have to explicitly use atomic API for data race accesses in Chrome. > > > > That might have been a conscious and deliberate choice on the part of > > the TSAN guys. Volatile does not imply any ordering in the standard > > (other than the compiler avoiding emitting volatile operations out of > > order), but some compilers did emit memory-barrier instructions for > > volatile accesses. Which resulted in a lot of problems when such code > > found compilers that did not cause the CPU to order volatile operations. > > > > So a lot of people decided to thrown the volatile baby out with the > > unordered bathwather. ;-) > > Thanks for the input, I think TSAN was indeed worried about > memory-ordering even if relaxed ordering was intended. I think there > is a way to tell TSAN to shut-up in such situations but in my last > Chrome sprint, I just used the atomic API with relaxed ordering and > called it a day. :-) Fair enough! Note that the Linux kernel's version of TSAN, which is KCSAN, does interpret volatile accesses more or less as if they were relaxed atomics. So TSAN could change, but I don't have a dog in that fight. ;-) Thanx, Paul
