Re: per cpun+ spin locks coexistence?

[Peter Teoh]

Thanks for the explanation, much apologies for this newbie discussion.
  But I still find it inexplicable:

On Mon, Mar 17, 2008 at 4:20 AM, Johannes Weiner <hannes@xxxxxxxxxxxx> wrote:
>
>  A per-cpu variable is basically an array the size of the number of
>  possible CPUs in the system.  get_cpu_var() checks what current CPU we
>  are running on and gets the array-element corresponding to this CPU.
>
>  So, really oversimplified, get_cpu_var(foo) translates to something like
>  foo[smp_processor_id()].
>

Ok, so calling get_cpu_var() always return the array-element for the
current CPU, and since by design, only the current CPU can
modify/write to this array element (this is my assumption - correct?),
and the other CPU will just read it (using the per_cpu construct).
So far correct?   So why do u still need to spin_lock() to lock other
CPU from accessing - the other CPU will always just READ it, so just
go ahead and let them read it.   Seemed like it defeats the purpose of
get_cpu_var()'s design?

But supposed u really want to put a spin_lock(), just to be sure
nobody is even reading it, or modifying it, so then what is the
original purpose of get_cpu_var() - is it not to implement something
that can be parallelized among different CPU, without affecting each
other, and using no locks?

The dual use of spin_lock+get_cpu_var() confuses me here :-).   (not
the per_cpu(), which I agree is supposed to be callabe from all the
different CPU, for purpose of enumeration or data collection).

-- 
Regards,
Peter Teoh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/