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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
