On Tue, 25 Jan 2005 19:21:10 +0100
J_rn Engel <[EMAIL PROTECTED]> wrote:
> On Tue, 25 January 2005 19:04:47 +0300, Evgeniy Polyakov wrote:
> > On Tue, 2005-01-25 at 16:34 +0100, Bartlomiej Zolnierkiewicz wrote:
> >
> > > Ugh, now think about that:
> > >
> > > CPU0 CPU1
> > > place1: place2:
> > > lock a lock b
> > > < guess what happens here :-) >
> > > lock b lock a
> > > ... ...
> >
> > :) he-he, such place are in add and remove routings, and they can not be
> > run simultaneously
> > in different CPUs.
>
> Makes my toenails curl. Something fun I might write someday is a
> statical (dead-)lock checker. The design is very simple:
>
> o Annotate code with the lock that could be taken.
> o Whenever getting a lock B, write down something like "A->B" for
> every lock A we already have.
> o Create a graph from the locking hierarchy obtained above.
> o Look for cycles.
>
> A cycle-free graph means that the code is deadlock-free. In the
> above, the graph surely has cycles. You could argue that the checker
> should be smarter, but then again - why should it? Is there a
> compelling reason why locking schemes as outlined above actually make
> the code better?
That will catch only simple cases - for the whole picture you need
to run graph generator from all allowed code pathes, but that
will require knowledge of the tested system, so it will not and
actually can not be absolutely generic.
> J_rn
>
> --
> It does not matter how slowly you go, so long as you do not stop.
> -- Confucius
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
