Re: recursive spinlocks. Shoot.

[Peter T. Breuer]

In article <20030520231013$[e-mail]> you wrote:
> From: Richard B. Johnson [mailto:[e-mail]]
>> 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. 

> 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