Kernel quote of the week

Posted Jun 11, 2021 0:22 UTC (Fri) by ncm (guest, #165)
Parent article: Kernel quote of the week

This is a good time to remind oneself that Linus is not always right. Often enough he is when some others are not. But anywhere he disagrees with Paul McKenney, my money will always be on Paul.

It was not long ago that Gcc obeyed the Standard requirements on volatile by issuing a load instruction immediately after each assignment to a volatile lvalue, because the assignment operation yields an rvalue that (they interpreted) requires an explicit load even if the result is immediately discarded. Writers of drivers for devices that would not tolerate an extra register read had to use an asm block. I don't doubt that Linus objected to that behavior, but I do doubt that the Standard was changed; rather, Gcc simply fell into line ignoring the requirement, like other compilers. Volatile has always had its own difficulties, and very rarely means what most using it hope.

I knew a core FreeBSD maintainer who insisted (and might still, if you asked) that a volatile flag was entirely sufficient to coordinate between threads on different cores, and firmly convinced our mutual employer. Good times.

Kernel quote of the week

Posted Jun 11, 2021 4:55 UTC (Fri) by vtjnash (subscriber, #141755) [Link] (1 responses)

Is what Linus arguing for basically what the working group's paper (including Paul) did initially examine as an alternative, but proceeded to show would cause mis-execution of various demonstrable counter-examples? <http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2556.html#Examples>. I recall seeing a somewhat later paper that showed some common ARM hardware was also found to be able to speculate certain dependent loads incorrectly, leading to further attempted (but unsuccessful) refinement of the definition of consume ordering. My impression was that most languages (such as Java) don't typically suffer these problems precisely because they are type-safe, while C allows the programmer to write programs that don't work with TBAA and discards pointer provenance, and thus are harder to compile "as intended". I don't know if that is true though, or if it is just because the volatile keyword in Java means sequentially consistent, and so is already a much stronger ordering than the discussion here intended.

I feel like I have clearly spent too much time attempting to learn about memory model details. And now on top of it, need to see if I can grok volatile_if someday.

Kernel quote of the week

Posted Jun 11, 2021 7:43 UTC (Fri) by ncm (guest, #165) [Link]

Like you, I don't know and don't want to know. Of three times I have cleverly used a consistency wesker than acquire/release, I have regretted it twice: once, because I could not then rule out its causing a failure (though it didn't, in the end), and again when circumstances surrounding its use changed enough that it was no longer correct.