On Tue, 2014-01-07 at 15:22 +0800, wyang wrote:
> On 01/07/2014 02:35 PM, Scott Wood wrote:
> > On Tue, 2014-01-07 at 09:00 +0800, wyang wrote:
> >> Yeah, Can you provide more detail info about why they can handle that
> >> case? The following is my understand:
> >>
> >> Let us assume that there is a atomic global variable(var_a) and its
> >> initial value is 0.
> >>
> >> The kernel attempts to execute atomic_add(1, var_a), after lwarx a async
> >> interrupt happens, and the ISR also accesses "var_a" variable and
> >> executes atomic_add.
> >>
> >> static __inline__ void atomic_add(int a, atomic_t *v)
> >> {
> >> int t;
> >>
> >> __asm__ __volatile__(
> >> "1: lwarx %0,0,%3 # atomic_add\n\
> >> ---------------------------------- <----------- interrupt
> >> happens-------> ISR also operates this global variable "var_a"
> >> such as also executing atomic_add(1, var_a). so the
> >> var_a would is 1.
> >> add %0,%2,%0\n"
> >> PPC405_ERR77(0,%3)
> >> " stwcx. %0,0,%3 \n\ <----- After interrupt code returns, the
> >> reservation is cleared. so CR0 is not equal to 0, and then jump the 1
> >> label. the var_a will be 2.
> >> bne- 1b"
> >> : "=&r" (t), "+m" (v->counter)
> >> : "r" (a), "r" (&v->counter)
> >> : "cc");
> >> }
> >>
> >> So the value of var_a is 2 rather than 1. Thats why i said that
> >> atomic_add does not handle such case. If I miss something, please
> >> correct me.:-)
> > 2 is the correct result, since atomic_add(1, var_a) was called twice
> > (once in the ISR, once in the interrupted context).
> Scott, thanks for your confirmation. I guess that Gavin thought that 1
> is a correct result. So thats why I said that if he wanna get 1,
> he should have responsibility to disable local interrupts.
If you disable interrupts, that will just delay the interrupt until
afterward, at which point the interrupt will increment var_a to 2.
> I mean that
> atomic_add is not able to guarantee that 1 is a correct result.:-)
Well, no. It's atomic_add(), not set_var_to_one(). :-)
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
