Re^2: Debugging lock ownership

Replies are listed 'Best First'.
Re^3: Debugging lock ownership by proceng (Scribe) on Aug 13, 2010 at 12:05 UTC
I have a multi-threaded Perl script that is experiencing lock contention issues. Is it possible to get the current lock owner somehow? This way I could debug which of my threads holds the locks most of the time. What platform? Which version of perl? Yes, I have implemented my own Thread::Queue. I needed some more functionality, and Thread::Queue is written in Perl anyway so there are no performance gains to be expected. What sort of functionality do you need? Read locking, exclusive locks, write locks on a specific region? Again, what platform (Linux, Solaris, Windows etc) are you on? Different ones have different quirks in file locks. Do you have access to a C compiler? I have already made some improvement in my locking problems. However, I'd prefer not to discuss that in more depth. If you don't tell us what you have already done, so that we can gain more insight into your problem, why should we reinvent the wheel? File and record locking procedures do not come under the heading of trade secrets, and can benefit from our collective expertise if you help us help you. So I repeat my original question: Is it possible to get the current lock owner somehow? I am expecting some low-level hack here. Perhaps if you explained more about the problem. It could be as simple as a lock file in a temp directory which contains the PID and TID of the locking thread. It could be as complicated as looking at the system structures (in /proc on Linux for example).	[reply]
Re^4: Debugging lock ownership by Anonymous Monk on Aug 13, 2010 at 16:43 UTC
I am using Perl 5.10.1 on Windows 7. I do not use file locks, but the lock function instead: `{ lock(@ResultQueue); # ... access @ResultQueue ... }` [download] Yes, I have access to a C compiler. I thank you for your reply, but I am not looking for a solution to my locking problem here. I am looking for a way to debug the problem myself.	[reply] [d/l]
Re^5: Debugging lock ownership by BrowserUk (Patriarch) on Aug 13, 2010 at 18:01 UTC
Yes, I have access to a C compiler. You could rebuild having defined `#define DEBUG_LOCKS` at the top of shared.xs. The problem is then how to relate the addresses displayed: 3e56088 waiting - owned by 3ef8c78 shared.xs:1032 3e56088 waiting - owned by 3ef8c78 shared.xs:1136 3e56088 waiting - owned by 3ef8c78 shared.xs:1208 3e56088 waiting - owned by 3ef8c78 shared.xs:1265 3e56088 waiting - owned by 3ef8c78 shared.xs:347 3e56088 waiting - owned by 3ef8c78 shared.xs:520 3e56088 waiting - owned by 3ef8c78 shared.xs:715 3e56088 waiting - owned by 4001018 shared.xs:1032 3e56088 waiting - owned by 4001018 shared.xs:1136 3e56088 waiting - owned by 4001018 shared.xs:1208 3e56088 waiting - owned by 4001018 shared.xs:1265 3e56088 waiting - owned by 4001018 shared.xs:347 3e56088 waiting - owned by 4001018 shared.xs:520 3e56088 waiting - owned by 4001018 shared.xs:715 3ef8c78 waiting - owned by 3e56088 shared.xs:1032 3ef8c78 waiting - owned by 3e56088 shared.xs:1136 3ef8c78 waiting - owned by 3e56088 shared.xs:1208 3ef8c78 waiting - owned by 3e56088 shared.xs:1265 3ef8c78 waiting - owned by 3e56088 shared.xs:347 3ef8c78 waiting - owned by 3e56088 shared.xs:520 3ef8c78 waiting - owned by 3e56088 shared.xs:715 3ef8c78 waiting - owned by 4001018 shared.xs:1032 3ef8c78 waiting - owned by 4001018 shared.xs:1136 3ef8c78 waiting - owned by 4001018 shared.xs:1208 3ef8c78 waiting - owned by 4001018 shared.xs:1265 3ef8c78 waiting - owned by 4001018 shared.xs:347 3ef8c78 waiting - owned by 4001018 shared.xs:520 3ef8c78 waiting - owned by 4001018 shared.xs:715 4001018 waiting - owned by 3e56088 shared.xs:1032 4001018 waiting - owned by 3e56088 shared.xs:1136 4001018 waiting - owned by 3e56088 shared.xs:1208 4001018 waiting - owned by 3e56088 shared.xs:1265 4001018 waiting - owned by 3e56088 shared.xs:347 4001018 waiting - owned by 3e56088 shared.xs:520 4001018 waiting - owned by 3e56088 shared.xs:715 4001018 waiting - owned by 3ef8c78 shared.xs:1032 4001018 waiting - owned by 3ef8c78 shared.xs:1136 4001018 waiting - owned by 3ef8c78 shared.xs:1208 4001018 waiting - owned by 3ef8c78 shared.xs:1265 4001018 waiting - owned by 3ef8c78 shared.xs:347 4001018 waiting - owned by 3ef8c78 shared.xs:520 4001018 waiting - owned by 3ef8c78 shared.xs:715 [download] Back to either thread ids or thread handles: `tid 3 : handle: 4065f20 tid 2 : handle: 3fd9810 tid 1 : handle: 3f393b0` [download] The "trick" would be unravelling the defnition of `aTHX`, but I've never gotten to the bottom of that piece of tortuous magic. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. RIP an inspiration; A true Folk's Guy	[reply] [d/l] [select]
Re^3: Debugging lock ownership by Anonymous Monk on Aug 13, 2010 at 17:14 UTC
I am expecting some low-level hack here. :-) The low level hacks are found here I was hoping Devel::Peek might reveal something but it doesn't :) `$ perl -Mthreads -MDevel::Peek -e"my $locked=1; my $unlocked=1; Dump($ +unlocked); lock($locked); Dump($locked)" SV = IV(0x98a490) at 0x98a494 REFCNT = 1 FLAGS = (PADMY,IOK,pIOK) IV = 1 SV = IV(0x3e8c10) at 0x3e8c14 REFCNT = 1 FLAGS = (PADMY,IOK,pIOK) IV = 1` [download] http://cpansearch.perl.org/src/JDHEDDEN/threads-shared-1.33/shared.xs says `/* User-level locks: This structure is attached (using ext magic) to any shared SV that` [download] so you might have luck using Variable::Magic to peek at the magic	[reply] [d/l] [select]