Recent Features
| |||||||||||||
The trouble with volatileThe trouble with volatilePosted May 16, 2007 11:43 UTC (Wed) by massimiliano (subscriber, #3048)In reply to: The trouble with volatile by IkeTo Parent article: The trouble with volatile
I agree that it is difficult to characterize an "access" is "volatile" or not, and I admit that I don't quite understand the statement. On the other hand, while "data is volatile" might be true for some time during the execution of the kernel, the "volatile" in the C language does not provide you the abstraction that you need most of the time. A funny thing, that made me ring a bell... In the .NET bytecode specification (called "CIL", Common Intermediate Language), there is the possibility to define something as "volatile", and... guess what? it is accesses that can be marked so, not variables! This reinforces my idea that the .NET standard is very well thought out: they really learned from the mistakes of the past, at least on technical issues.
(Log in to post comments)
The trouble with volatile Posted May 16, 2007 16:07 UTC (Wed) by giraffedata (subscriber, #1954) [Link] In the .NET bytecode specification (called "CIL", Common Intermediate Language), there is the possibility to define something as "volatile", and... guess what? it is accesses that can be marked so, not variables! You're implying that "volatile" in C was a mistake. It wasn't. While it isn't useful for coordinating threads on separate processors in a 2007 Linux kernel, it's just fine for what it was designed for: coordinating a CPU with a memory-mapped I/O device in the early '80s. I don't know anything about .NET, but I think the most you can conclude from this volatile thing is that .NET is designed for more modern computers than ANSI C. And that the spec is written poorly -- "volatile" is the wrong word for this.
|
|||||||||||||