[Openmcl-devel] lock owner: how to access?

[Gary Byers]

The only thing you can generally do (outside of a context like the kernel
debugger, where all other threads are stopped) is answer the question
"what thread owned this lock a few cycles ago, when I asked ?"  The answer
to that question is either useful or misleading, and there's no general
way of knowing which.

So, you can't write a LOCK-OWNER function that's guaranteed to return
a useful, trustworthy answer, but you can write a POSSIBLE-LOCK-OWNER
function that might be useful.

For a RECURSIVE-LOCK (something made by MAKE-LOCK),

(defun possible-recursive-lock-owner (lock)
   (let* ((tcr (ccl::%get-object (ccl::recursive-lock-ptr lock) target::lockptr.owner)))
     (unless (eql 0 tcr) (ccl::tcr->process tcr))))

That's almost trivial, and will often return a useful answer.  If we do:

? *current-process*
#<TTY-LISTENER listener(1) [Active] #x30200051AFED>
? (let* ((lock (make-lock)))
   (with-lock-grabbed (lock) (possible-recursive-lock-owner lock)))
#<TTY-LISTENER listener(1) [Active] #x30200051AFED>

then we can probably trust that answer completely.

If we ask "who owns a heavily contended global lock?", we have to understand
that that's not necessarily a meaningful question.  If we're really sure that
whoever owns the lock has owned it longer than we think it should have and
want to start to try to figure out why, then the answer is about as trustworthy
as our diagnosis of the problem.  I'm fairly sure that I've misdiagnosed
problems like this, and I've probably failed to take answers like this with
a large enough grain of salt.

The fact that POSSIBLE-RECURSIVE-LOCK-OWNER needs as many disclaimers
as it does may or may not justify the fact that it's never been
defined, but it has a lot to do with it.  It's also true that it can
give a useful and meaningful answer, and that probably is enough to
justify its existence (with lots of disclaimers that everyone will
get tired of hearing but are nonetheless valid.)





On Fri, 1 Jul 2011, Alexander Repenning wrote:

> In cases where some kind of deadlock includes the user/"initial" thread CCL becomes unresponsive (understandably and justifiably). OS X will show the spinning beach ball and there is not much left for the user to do other than to force quit the app. However, a separate "deadlock detection" thread can continue even in these situations and could 
do a little introspection of threads and locks to potentially detect a deadlock situation. This could be very useful for debugging as it could spit out some into into alt console.
>
> Question: there is some introspection that could be done on threads/processes but what about locks? If, say, process p1 grabs lock l1, is there a way to access this information? In other words, how would one write a (grabbed-by <lock>) function?
>
> Alex
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>