Messages in this thread |  | | | Date | Fri, 17 Aug 2007 18:20:25 +0530 (IST) | | From | Satyam Sharma <> | | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| |
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote: > > On Fri, 17 Aug 2007, Nick Piggin wrote: > > > Satyam Sharma wrote: > > > > > > It is very obvious. msleep calls schedule() (ie. sleeps), which is > > > always a barrier. > > > > Probably you didn't mean that, but no, schedule() is not barrier because > > it sleeps. It's a barrier because it's invisible. > > Where did I say it is a barrier because it sleeps?
Just below. What you wrote:
> It is always a barrier because, at the lowest level, schedule() (and thus > anything that sleeps) is defined to always be a barrier.
"It is always a barrier because, at the lowest level, anything that sleeps is defined to always be a barrier".
> Regardless of > whatever obscure means the compiler might need to infer the barrier. > > In other words, you can ignore those obscure details because schedule() is > always going to have an explicit barrier in it.
I didn't quite understand what you said here, so I'll tell what I think:
* foo() is a compiler barrier if the definition of foo() is invisible to the compiler at a callsite.
* foo() is also a compiler barrier if the definition of foo() includes a barrier, and it is inlined at the callsite.
If the above is wrong, or if there's something else at play as well, do let me know.
> > > The "unobvious" thing is that you wanted to know how the compiler knows > > > a function is a barrier -- answer is that if it does not *know* it is not > > > a barrier, it must assume it is a barrier. > > > > True, that's clearly what happens here. But are you're definitely joking > > that this is "obvious" in terms of code-clarity, right? > > No. If you accept that barrier() is implemented correctly, and you know > that sleeping is defined to be a barrier,
Curiously, that's the second time you've said "sleeping is defined to be a (compiler) barrier". How does the compiler even know if foo() is a function that "sleeps"? Do compilers have some notion of "sleeping" to ensure they automatically assume a compiler barrier whenever such a function is called? Or are you saying that the compiler can see the barrier() inside said function ... nopes, you're saying quite the opposite below.
> then its perfectly clear. You > don't have to know how the compiler "knows" that some function contains > a barrier.
I think I do, why not? Would appreciate if you could elaborate on this.
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/
|  |