recursive spinlocks. Shoot.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · In article <[email protected]> you wrote:
From: Richard B. Johnson [mailto:[email protected]]
Quoted 3 lines
The lock must guarantee that recursion is not allowed. Or to put it more bluntly, the lock must result in a single thread of execution through the locked object.
Where the HECK do you get that load of bull? The one requirement of a MUTUAL EXCLUSION PRIMITIVE (a.k.a. mutex, a.k.a. lock) is *MUTUAL* EXCLUSIVITY.
:-) this reminds me of the post I didn't make.
Quoted 1 line
All else is unfounded blither.
Hey, that was the word I used in the post I didn't make! I'm sort of glad I didn't say it out loud - it ruins the argument.
Anyhow, I have now written a tool that can detect various improper uses of locks. I've started out by detecting sleep under spinlock, but I'll go on to other deadlocks.
% ./c ../dbr/1/sbull..c
<function name=sbull_ioctl file=sbull.c line=171 attr=S_SLEEP> <function name=sbull_request file=sbull.c line=361 attr=S_SLEEP> %
Detects two functions in the target file that sleep. For that it had to analyse 28K lines of C. Put a spinlock in the wrong place and ...
% ./c test16
sleep under spinlock at file="test16" line=30 <function name=sbull_open file=test16 line=1 attr=S_SLEEP>
(I excised a function to fiddle with and put a call to one of the other two in under a lock).
I'll make this available. As soon as I figure out some more of how to define C contexts. It uses a database and I'm having trouble deciding where something is first defined in C.
Peter