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

[Nick Piggin <piggin@cyberone.com.au>]

Satyam Sharma wrote:
> On Fri, 17 Aug 2007, Nick Piggin wrote:

> > > Sure, now
> > > that I learned of these properties I can start to audit code and insert
> > > barriers where I believe they are needed, but this simply means that
> > > almost all occurrences of atomic_read will get barriers (unless there
> > > already are implicit but more or less obvious barriers like msleep).
> >
> > You might find that these places that appear to need barriers are
> > buggy for other reasons anyway. Can you point to some in-tree code
> > we can have a look at?
>
>
> Such code was mentioned elsewhere (query nodemgr_host_thread in cscope)
> that managed to escape the requirement for a barrier only because of
> some completely un-obvious compilation-unit-scope thing. But I find such
> an non-explicit barrier quite bad taste. Stefan, do consider plunking an
> explicit call to barrier() there.

It is very obvious. msleep calls schedule() (ie. sleeps), which is
always a barrier.

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. If the whole msleep call chain
including the scheduler were defined static in the current compilation
unit, then it would still be a barrier because it would actually be able
to see the barriers in schedule(void), if nothing else.
-
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/