Messages in this thread |  | | | Date | Fri, 17 Aug 2007 22:56:41 +1000 | | From | Nick Piggin <> | | Subject | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| |
Satyam Sharma wrote:
> >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". >
... because it must call schedule and schedule is 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. >
Right.
>>>>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". >
_In Linux,_ 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. >
You're getting too worried about the compiler implementation. Start by assuming that it does work ;)
>>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. >
If a function is not completely visible to the compiler (so it can't determine whether a barrier could be in it or not), then it must always assume it will contain a barrier so it always does the right thing. - 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/
|  |