Re: racy acccess in kern_runq.c

[Don Lee <MacPPC2%c.icompute.com@localhost>]

Please educate me. It’s been a while for me.

Writing Kernel code *requires* knowledge of what code is generated sometimes. In my experience, there have been standard techniques, like pragmas and insertions of assembly code to suppress this sort of undesirable optimization.

Don’t those techniques exist any more? My compiler friends used to put them in for just this purpose, and they tried to make them as portable as possible. Surely GCC does this. No?

Inquiring minds…

-dgl-

> On Dec 6, 2019, at 1:44 PM, <Paul.Koning%dell.com@localhost> <Paul.Koning%dell.com@localhost> wrote:
> 
> 
> 
>> On Dec 6, 2019, at 10:21 AM, Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:
>> 
>> 
>> [EXTERNAL EMAIL] 
>> 
>>> Compilers have became much more aggressive over the years.  But they
>>> are allowed to be so by the C standard.  Specifically, in addition to
>>> code-level re-ordering, plain accesses (loads/stores) are subject to
>>> load/store fusing, tearing as well as invented loads/stores.
>> 
>> Then, honestly, it sounds to me as though "the latest revision of C" is
>> no longer an appropriate language for writing kernels.  I see no reason
>> to twist the kernel code into a pretzel to work around latitude a new
>> language gives to its compilers - and that's what C11 is, a new
>> language, albeit one closely related to various previous languages.
>> 
>> One of the prime considerations when choosing a language and/or
>> compiler for building a kernel is that it produce relatively
>> predictable code, for exactly this kind of reason.  If the latest C and
>> the latest gcc no longer do that, then IMO they are no longer
>> appropriate for writing/compiling kernels.
> 
> C11 isn't all that new, of course.  And I don't know if the rules about optimization that you object to are anywhere near that new in any case.  What seems to be the case instead is that compilers are more and more doing what the language has for a long time allowed them to do.
> 
> Consider for example "Undefined behavior -- what happened to my code?" by Wang et al. (MIT and Tsinghua University).  It describes all sorts of allowed transformations that come as a surprise to programmers.
> 
> Yes, it certainly would be possible to create a programming language with less surprising semantics.  C is not in any way shape or form a clean language with clean semantics.  But as for wanting predictable code, that is certainly doable.  Unfortunately, it requires a sufficiently deep understanding of the rules of the language.  Typical textbooks are not all that good for this, they are too superficial.  The language standard tends to be better.  But again, a problem with most programming languages is that their semantics are not well defined and/or much more complex than they should be.  Programmming in C++ is particularly scary for this reason, but C is also problematic.  For clean semantics, I like ALGOL; too bad it is no longer used, though it did at one time serve to build successful operating systems.
> 
> 	paul
>