This page is part of the web mail archives of SRFI 18 from before July 7th, 2015. The new archives for SRFI 18 contain all messages, not just those from before July 7th, 2015.
Marc, > Under what authority does T3 terminate T1? As I have pointed out in > the spec, thread-terminate! must be used very carefully to avoid > stopping a thread at an "unsafe" point (such as in the middle of a > critical section). But that was exactly the point of the original example: T1 was NOT in an explicit critical section, when it was killed. As I understand the example uses mutexes specifically for the purpose _other_ than to introduce a critical section. It appears that you have already given a solution to the problem. In a message http://srfi.schemers.org/srfi-18/mail-archive/msg00038.html you showed an example that uses a mutex just to guard a critical section. If that example is modified as (define (put! obj) (mutex-lock! mutex) (let loop () (if full? (begin (condition-variable-wait! put-condvar mutex) (loop)) (begin (set! cell obj) (set! full? #t) (condition-variable-signal! get-condvar) (mutex-unlock! mutex))))) (that is, signaling on condvar is moved inside the critical section), the example seems to become immune to the unsafe dying problem. When a thread T1 executes put! and enters a critical section, and is later killed or throws a lethal exception at _any point_ after mutex-lock!, the mutex becomes abandoned. Therefore, a thread T2 that wishes to manipulate the mailbox will have to deal with a "abandoned mutex exception". At least T2 will be alerted to the fact the mailbox is stale and has to be avoided. In the original example, if thread T1 is killed at an unfortunate moment, T2 will just block forever. T2 will never find out that the data structure, mailbox, became inconsistent. It appears one can even claim that in the latter example, the mutex is not-abandoned if and _only_ if the mailbox is consistent and will not cause a deadlock for any thread that wishes to use it.