Re: Tracking down LORs

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.

rik