lkml.org 
[lkml]   [2007]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/24] make atomic_read() behave consistently on alpha
Date
>> The compiler is within its rights to read a 32-bit quantity 16 bits at
>> at time, even on a 32-bit machine. I would be glad to help pummel any
>> compiler writer that pulls such a dirty trick, but the C standard
>> really
>> does permit this.
>
> Yes, but we don't write code for these compilers. There are countless
> pieces of kernel code which would break in this condition, and there
> doesn't seem to be any interest in fixing this.

"Other things are broken too". Great argument :-)

> Sequence points enforce read-after-write ordering, not
> write-after-write.

Sequence points order *all* side effects; sequence points exist in the
domain of the abstract sequential model of the C language only. The
compiler translates that to machine code that is equivalent to that C
code under the "as-if" rule; but this is still in that abstract model,
which doesn't include things such as SMP, visibility by I/O devices,
store queues, etc. etc.

> We flush writes with reads for MMIO because of this effect as well as
> the CPU/bus effects.

You cannot flush all MMIO writes with reads; this is a PCI-specific
thing. And even then, you need more than just the read itself: you
have to make sure the read completed and returned data.

>> In short, please retain atomic_set()'s volatility, especially on those
>> architectures that declared the atomic_t's counter to be volatile.
>
> Like i386 and x86_64? These used to have volatile in the atomic_t
> declaration. We removed it, and the sky did not fall.

And this proves what? Lots of stuff "works" by accident.


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-08-09 21:01    [from the cache]
©2003-2011 Jasper Spaans