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

[Alexander Repenning]

This should work fine for the kind of deadlock detection we have in mind. 

thanks,  Alex



On Jul 2, 2011, at 2:35 AM, Gary Byers wrote:

> 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
>> 
>> 

Prof. Alexander Repenning

University of Colorado
Computer Science Department
Boulder, CO 80309-430

vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20110705/6bd206f4/attachment.htm>