![]() | |||||||||||||
Messages in this thread |
On 5/12/07, H. Peter Anvin <hpa@zytor.com> wrote: > Satyam Sharma wrote: > > > >> + - Pointers to data structures in coherent memory which might be > >> modified > >> + by I/O devices can, sometimes, legitimately be volatile. A ring > >> buffer > >> + used by a network adapter, where that adapter changes pointers to > >> + indicate which descriptors have been processed, is an example of > >> this > >> + type of situation. > > > > is a legitimate use case for volatile is still not clear to me (I > > agree with Alan's > > comment in a previous thread that this seems to be a case where a memory > > barrier would be applicable^Wbetter, actually). I could be wrong here, so > > would be nice if Peter explains why volatile is legitimate here. > > > > Otherwise, it's fine with me. > > > > I don't see why Alan's way is necessarily better; Because volatile is ill-defined? Or actually, *undefined* (well, implementation-defined is as good as that)? It's *so* _vague_, one doesn't _feel_ like using it at all! We already have a complete API containing optimization barriers, load/store/full memory barriers. With well-defined and well-understood semantics. Just ... _why_ use volatile? > it should work but is It will _always_ work. In fact you can't really say the same for volatile. We already assume the compiler _actually_ took some pains to stuff meaning into C's (lack of) definition of volatile and implement it -- but in what sense, nobody knows (the C standard doesn't, so what are we). > more heavy-handed as it's disabling *all* optimization such as loop > invariants across the barrier. This is a legitimate criticism, I agree. Thanks, Satyam - 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-05-12 08:19 [from the cache] ©2003-2008 | |||||||||||||