Tracking down LORs
rik at cronyx.ru
Fri Aug 20 11:32:09 PDT 2004
John Baldwin wrote:
>On Friday 20 August 2004 04:08 am, Roman Kurakin wrote:
>>Robert Watson wrote:
>>>On Fri, 20 Aug 2004, Roman Kurakin wrote:
>>>> Currently I am trying to track down a couple of LORS in my code.
>>>>But it seems that I do not undestand smth or all things id realy so bad.
>>>I find it's very helpful to add lock orders to the hard-coded lock order
>>>table in subr_witness.c. Without hard-coded entries, WITNESS will
>>>dynamically build an order based on observed lock use. This is generally
>>>fine, but once in a while the "wrong" order will be used before the
>>>"right" order, so the lock order warning will print for the "right" order,
>>>leaving less useful debugging information. The table allows the
>>>definition of partial orders, so you can specify relationships between
>>>subsets of mutexes of interest. WITNESS will flesh out remaining orders
>>>through dynamic discovery.
>>I'll try to go this way, since I am in dead end.
>Note that some lock orders as also inferred via transitivity.
>For example, let's say you have three locks a, b, and c. One thread locks a
>then b, so witness saves that order. A second thread locks b then c, so
>witness saves that order. If a third thread tries to lock c then a, an LOR
>will result. This is similar to how > is transitive, i.e. if a > b and b >
>c, then a > c.
It looks like I have smth like that. But I am get stuck with boot loader
problem for now :-(
I switched to that problem since that machine was the only that could
work fast enough
and has ISA slots.
Than I get back to LOR problem and solve it, I guess I'll have to write
some FAQ that
will help to track down LORs.
Thanks to all for replies! Now I have some ideas to move on.
More information about the freebsd-current