Re: Pthread mutex lock validator

[sanketh nalli <nalli dot sanketh at gmail dot com>]

On Thu, Apr 19, 2012 at 10:22 PM, sanketh nalli <nalli.sanketh@gmail.com> wrote:
> Hi,
> I have answered your questions inline.
>
> On Wed, Apr 11, 2012 at 1:14 AM, Carlos O'Donell
> <carlos@systemhalted.org> wrote:
>>
>> On Tue, Apr 10, 2012 at 3:16 PM, sanketh nalli <nalli.sanketh@gmail.com> wrote:
>> > As part of my senior thesis, I worked on writing a
>> > lock dependency validator for libpthread,
>> > which is similar to lockdep in Linux.
>> > My codes are available here :
>> > git@github.com:Sanketh/liblockdep.git
>> >
>> > I wish to contribute this to glibc/nptl.
>>
>> Thank you for contacting the community!
>>
>> We are always interested in more volunteers :-)
>>
>> Could you please talk about:
>>
>> * License and copyright?
>> ?- Contributing to glibc community requires that the copyright of
>> your contribution be given to the FSF.
>> ?- Who owns the license and copyright to the code?
>> ?- Your school?
>> ?- You?
>> ?- Are you able to sign a copyright assignment form for glibc?
>
>
> Well, no body has the copy rights to the code, not me nor my college.
> But, I borrowed the idea and some of the code from the Linux kernel.
> And the copyrights for that particular piece of code are with Ingo Molnar
> and Peter Zijlstra.
>
>>
>>
>> * Theory of operation?
>
>
> The lock-validator tracks the sequence of locks taken when the program
> is in execution. It plots a resource graph where the nodes are the locks.
> There is a directed edge from node i to node j, if lock j was taken after
> lock i.
>
> The validator runs BFS (breadth first search) over the graph every time
> a lock is requested. If any cycles are detected upon the acquisition of
> the lock, they are reported as deadlocks.
> Bugs are reported even if the current locking scenario does not cause
> any deadlock at this point.
> I.e. if anytime in the past two locks were taken in a different order,
> even if it happened for another task, even if those were different
> locks (but of the same class as this lock), this code will detect it.
>
> The validator also checks for recursive locks i.e. lock taken twice
> and lock release bug i.e a lock being released without ever being held.
>
>>
>>
>> * Current results against glibc trunk?
>>
> i am not sure what this means. Please elaborate.
>
>>
>> * Do you plan to stay involved with glibc and maintain this test?
>
>
> Yes... I plan to stay involved and merge this in the main stream library.
>>
>>
>> Cheers,
>> Carlos.
>
>
>
>
> --
> Regards
>
> Sanketh Nalli
> B.Tech Final year
> Department of Information Technology
> National Institute of Technology, Karnataka



-- 
Regards

Sanketh Nalli
B.Tech Final year
Department of Information Technology
National Institute of Technology, Karnataka