Re: [PATCH 0/24] make atomic_read() behave consistently across allarchitectures

[Nick Piggin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/