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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Satyam Sharma <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Paul Mackerras <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Herbert Xu <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Paul Mackerras <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Herbert Xu <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Stefan Richter <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Herbert Xu <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Stefan Richter <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Stefan Richter <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Herbert Xu <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: "Paul E. McKenney" <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Nick Piggin <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Stefan Richter <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Nick Piggin <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- From: Satyam Sharma <[email protected]>
- Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- Prev by Date: Re: [PATCH/RFC 3/4]Introduce "account modifiers" mechanism
- Next by Date: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- Previous by thread: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- Next by thread: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
- Index(es):
 |