I was thinking about this one last night, and it's trickier than I first thought.
L = lock, T = trylock Thread1: L1 L2 Thread2: L2 T1 Not a deadlock because the trylock will just fail. However, suppose we have: Thread1: L1 L2 Thread2: L2 T1 And then later: Thread 3: L1 L2 When helgrind handles L2, it would already find the graph edge L1 -> L2 so wouldn't it just return since that is the "correct order"? David sent me some past e-mail and I saw some comments about putting lock vs trylock into the graph. Seems to me that when processing T2, helgrind would not report a problem, but would add the T2 -> L1 link, and would also need to ensure that if L1 -> L2 happens in the future, it is reported. -----Original Message----- From: David Faure [mailto:fa...@kde.org] Sent: Friday, September 27, 2013 9:38 AM To: valgrind-users@lists.sourceforge.net Cc: Phil Longstaff Subject: Re: [Valgrind-users] FW: Helgrind to-do list On Wednesday 25 September 2013 18:24:59 Phil Longstaff wrote: > * Don't update the lock-order graph, and don't check for errors, > when a "try"-style lock operation happens (e.g. pthread_mutex_trylock). > Such calls do not add any real restrictions to the locking order, > since they can always fail to acquire the lock, resulting in the > caller going off and doing Plan B (presumably it will have a Plan B). > Doing such checks could generate false lock-order errors and confuse users. Assuming this one is what you numbered #4 (i.e. that you started to count at 1 and not 0) :-), then it's something I had started a long time ago, details are in the archive for this mailing-list (Nov 2012) (actually let me attached the mails here for convenience), and the testcase is at https://bugs.kde.org/show_bug.cgi?id=243232 I would be very very glad if you could take over, I lack time and valgrind knowledge. I'm also attaching my very preliminary & very old patch for it. IIRC it needs to be updated to actually implement what was discussed in the attached emails, in addition to making it work in the first place... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
