lkml.org 
[lkml]   [2003]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: recursive spinlocks. Shoot.
Robert White writes:
> This will, hopefully, be my out-comment on this thread.
>

[...]

>
> 4) All locks (spin or otherwise) should obviously be held for the shortest
> amount of time reasonably possible which still produces the correct result.
>
> If this needs explaining... 8-)

It surely does.

Consider two loops:

(1)

spin_lock(&lock);
list_for_each_entry(item, ...) {
do something with item;
}
spin_unlock(&lock);

versus

(2)

list_for_each_entry(item, ...) {
spin_lock(&lock);
do something with item;
spin_unlock(&lock);
}

and suppose they both are equally correct. Now, in (2) total amount of
time &lock is held is smaller than in (1), but (2) will usually perform
worse on SMP, because:

. spin_lock() is an optimization barrier

. taking even un-contended spin lock is an expensive operation, because
of the cache coherency issues.

>

[...]

>
> Rob.
>

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

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.098 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site