der Mouse <mouse@Rodents.Montreal.QC.CA> writes:

> This is not actually necessary.  (If NetBSD wants to make it true by
> fiat for NetBSD code, that's fine, but it should not be confused with
> any underlying necessity.)

I would prefer to make it true. Essentially, I would like to remove
volatile from the language we use. There may be correct ways to use
it, but as this back-and-forth exchange demonstrates, they are subtle
and require a lot of details to be correct. I don't think that the
project has the necessary resources to ensure that such difficult uses
are correct; therefore they should be eliminated.

> Provided stores and reads are serialized in
> some order, with each accessor's accesses performed in the order
> they're issued, it's possible to interlock without additional help.

Where are you going to get this provision? It's certainly not true in
general, and I'm not even sure it's guaranteed on all uniprocessors we
care about.

> Except it actually doesn't - provided sc->flags is volatile.  And
> indeed it quite likely is not a good idea for it to, if the loop does
> not loop more than some small number of times on the average (or if
> this is early enough that the scheduler behind tsleep() isn't up).

Potentially unbounded busy-waiting is a sin in its own right, as
Andrew mentioned.

> Still doesn't help if the data being examined is file-static and does
> not have its address stored anywhere global and thus is not modifiable
> by tsleep() according to the C virtual machine; the compiler is then
> perfectly within its rights to keep the flags word in a register across
> the tsleep().

This is an interesting point; I'm not sure it matters in
practice. It's not completely correct; if there are non-static,
non-address-taken functions that can access the file-level static,
then the compiler has to assume that tsleep() might call one of
those. If all the other functions that touch the data are static,
uncalled by non-static functions, and don't have their address
somewhere global, then you may be correct, but I don't think current
compilers are able to take advantage of that.

          - Nathan