lkml.org 
[lkml]   [2008]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: per cpun+ spin locks coexistence?
Date
Hi,

"Peter Teoh" <htmldeveloper@gmail.com> writes:

> 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?

You ignore the fact that there are structures and pointers in C :) One
and the same object may be referenced from different structure objects.

For example you have an object foo saved in a cpu-local variable and
this object references another object bar (foo.bar), you might do
whatever you want to do with foo. But if bar is a structure you might
still have to lock when you want to change the fields of it to prevent
races if this bar object can be referenced from another point like an
instance of some_struct:

PER-CPU [foo|foo|foo]
| | |
| | \
| \ +---> [bar]
\ +---> [bar]
+---> [bar] <--+
\
[some_struct]

A foo _might_ be protected by cpu-locality but as you can see, bar can
only be changed under lock if it is modified through foo _and_
some_struct.

I hope this clears it. Please correct me if I am wrong or supply a
better scenario than this ;)

Hannes


\
 
 \ /
  Last update: 2008-03-17 18:57    [W:0.065 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site