On Mon, 4 Aug 2025 09:20:43 -0300 Henrique de Moraes Holschuh <[email protected]> wrote:
> Em 04/08/2025 08:15, Roberto A. Foglietta escreveu: > > On Mon, 4 Aug 2025 at 13:11, Denys Vlasenko <[email protected]> > > wrote: > >> The correct fix is to specify the pointer in question as "volatile" > >> variable, so that gcc stops making assumptions about its liveness. > > > > You are right as a manual, Denis. > > > > ...but god knows what gcc does with a volatile which is not associated > > with a hardware I/O line. (LOL) > > Compilers never cared about this. "volatile" in C is very well defined: > it simply means every time the memory location is accessed, the compiler > must issue a fresh read. > > And that's *all* it does, which is quite often "not enough". It is > indeed a real pitfall that has claimed a lot of victims over the years. > > volatile isn't "read once" or "write once": the compiler can output code > that will read a volatile variable many times even if the load shows up > only once in the source code. In fact, declaring something volatile > INCREASES the chances the compiler will load it more than once. Are you sure, that sounds wrong to me. What catches people out is that without volatile the compiler can (is allowed to) read a variable twice even if it only appears once in the source. (Although I can't remember whether the gcc/clang maintainers have said that the current versions will actually do it.) > > volatile isn't a compile barrier: the compiler can still move the > loads/stores to volatile variables around, unless something else in the > code forbids it to. It must not reorder loads and stores to the same > volatile variable, and it must not elide loads because it just stored > something and that data is still in a register, but that's it. I'm sure volatile is a compile barrier w.r.t other volatiles. (This doesn't mean the the cpu will execute the accesses in order.) > > volatile loads and stores are not atomic, and they are not synchronizing > (memory barriers) either. A store to a volatile variable can result > into the compiler generating read-modify-write code for some types, for > example. I think loads and stores (but not increments) need to be atomic. Certainly any compiler used to build the Linux kernel requires that a volatile access (done by accessing though a volatile cast) generates a single cpu memory access instruction, MSVC does the same. There have been issues where the compile would access a volatile variable (possibly as RMW) when accessing an adjacent sub-word item. While the standard might allow that both gcc and clang have been fixed to not do it. > There is *nothing* in volatile that ensures no mixing of > concurrent writes won't be observed by a concurrent reader. Evidently, > there is also no implied ordering between reads or writes from separate > hardware threads. True - because the cpu is allowed to re-order memory accesses. But a variable of type 'atomic_t' is guaranteed to be read/written is a manner that multiple threads will never see 'corrupt' values. While there are alternatives, it will be just a volatile variable. > > Granted, some CPU architectures might give you atomic behavior on > load/store of for some types "for free", and paper over *some* such bugs > on code that misused volatile. E.g. x86 and x86-64 are not going to > allow a concurrent load to observe a mixed concurrent writes for aligned > int32_t (among many other types). This still gives you no > synchronization, and a stored value by one hardware thread might take > its sweet time to become visible to other hardware threads. > > Now, when doing memory-mapped I/O, *SOME* architectures will have > specific hardware access modes (e.g. uncached) for that address space > region, which may paper over some of the above issues. Some would call > C code that depends on such behavior buggy. > > > So, when two threads of execution could access the same memory location > (and that certainly includes parent and child from fork() and friends), > if any of these accesses could be a store or you need ordering of any > sort, you will most likely need more than just "volatile" to ensure it > will always behave as intended. That is correct due to cpu memory re-ordering. But, in this case, a global volatile variable should suffice. David _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
