[Openmcl-devel] process-interrupt and locks leading to deadlocks

[Gary Byers]

Sorry for not replying earlier.

Many things in CCL (including but not limited to streams, hash tables,
packages in some or all cases) use locks; they're also used in lower-level
parts of the runtime, including the kernel.  There isn't any sort of big
list of all things that might use locks; there isn't any (practical) way
of finding out what locks a thread holds or of finding out what thread(s)
hold(s) a given lock.

If you try to wait for a lock in code invoked by PROCESS-INTERRUPT, there's
the possibility that you'll run into the kind of deadlock that you're seeing
(the lock is owned by some other thread that's waiting for some lock or other
resource that you own.)

If this is a realistic possibility, I think that the only current
alternative is to try to obtain the lock/semaphore without waiting
(TRY-LOCK, TIMED-WAIT-ON-SEMAPHORE with small/0 timeout) and if that
fails to return from and reschedule the interrupt.

On Tue, 6 Aug 2013, Florian Dietz wrote:

> I have two threads, A and B. I am using process-interrupt to interrupt thread 
> A. The interruption can only finish once thread B has also processed some 
> information and waits on thread B via a semaphore. This can lead to a 
> deadlock if A gets interrupted while holding a lock that is needed in B. I 
> have tried to prevent this problem by encapsulating all locks with 
> without-interrupts.
>
> Unfortunately, some processes seem to use implicit locks that I am not aware 
> of. Is there an easy way to find out which functions could be at fault 
> without manually looking up the definition of every function I am using? 
> Also, could error-handling have something to do with this error?
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>