lkml.org 
[lkml]   [2008]   [Mar]   [17]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 18 Mar 2008 01:06:33 +0800
From"Peter Teoh" <>
SubjectRe: per cpun+ spin locks coexistence?
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@saeurebad.de> 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


\
 
 \ /
  Last update: 2008-03-17 18:09    [from the cache]
©2003-2008