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? Jörn -- It does not matter how slowly you go, so long as you do not stop. -- Confucius - 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/
