Messages in this thread | | | Date | Mon, 13 Sep 1999 06:19:10 -0700 (PDT) | From | Robert Dinse <> | Subject | spin_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/
| |