lkml.org 
[lkml]   [1999]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectspin_lock and linux philosophy question...


I've been trying to understand how things work (and why sometimes they
don't on my machines), and looking at code has brought up a couple of general
philosophical language.

One aspect of Linux that is very different from other versions of Unix
that I have had experience with, with the exception of Unix-RTR, is that other
versions of Unix tend to panic whenever they run into any abnormal conditions.
Go to free an already free inode, panic, etc. Linux on the other hand, for the
most part, handles these situations, printing some message to inform us of the
problem and then moves on, or in some cases terminates an offending process
with an OOPS, but that's a whole lot better than the entire machine crashing.

I am curious why the debug versions of the spin_lock routines on the Sparc
seem to be the exception to this? If I am interpreting this right, basically,
a counter is initialized to 100000000 and then each loop while the lock is
still held, decremented. When the counter reaches zero, it bitches but it
continues to loop and the whole machine locks up.

When this occurs, whether it is do to a logic flaw, race condition, or
some hardware problem, missed interrupt that would have released the lock, etc,
why not have the routine remove the lock when it times out, print a message to
the console, and move on?

But that brings up a larger question of why there are spin locks at all?
If a CPU can't be doing one thing because a particular resource is unavailable
being used by another CPU, why isn't it then sent off to do something else?



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

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