lkml.org 
[lkml]   [2007]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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/

    \
     
     \ /
      Last update: 2007-08-17 14:45    [W:0.025 / U:29.284 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site