Hi!
> > AFAICT this fails to mention... Is local_t as big as int? As big as
> > long? Or perhaps smaller because high bits may be needed for locking?
>
> Hi Pavel,
>
> Here is an update that adds the information you mentionned in this reply and
> the
> one to Andrew. Thanks for the comments.
>
> Mathieu
>
>
> index dfeec94..bd854b3 100644
> --- a/Documentation/local_ops.txt
> +++ b/Documentation/local_ops.txt
> @@ -22,6 +22,13 @@ require disabling interrupts to protect from interrupt
> handlers and it permits
> coherent counters in NMI handlers. It is especially useful for tracing
> purposes
> and for various performance monitoring counters.
>
> +Local atomic operations only guarantee variable modification atomicity wrt
> the
> +CPU which owns the data. Therefore, care must taken to make sure that only
> one
> +CPU writes to the local_t data. This is done by using per cpu data and making
> +sure that we modify it from within a preemption safe context. It is however
> +permitted to read local_t data from any CPU : it will then appear to be
> written
> +out of order wrt other memory writes on the owner CPU.
So it is "one cpu may write, other cpus may read", and as big as
long. Are you sure obscure architectures (sparc?) can implement this
in useful way? ... maybe yes, unless obscure architecture exists where
second other cpu can see garbage data when first cpu writes into long
...?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/
