<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><br class=""></div><div class="">Apologies for these piece-wise emails.</div><div class=""><br class=""></div><div class="">I tried to replicate armcl threading problems described in</div><div class=""><a href="https://trac.clozure.com/ccl/ticket/1257" class="">https://trac.clozure.com/ccl/ticket/1257</a> </div><div class="">and I think I might have found some other issues, as well as a clue to a possible cause</div><div class=""><br class=""></div><div class="">See <a href="https://pastebin.com/2x3mcHMc" class="">https://pastebin.com/2x3mcHMc</a></div><div class=""><br class=""></div><div class="">I found that </div><div class=""><br class=""></div><div class="">* a simple thread test with a bit of garbage generation in threads fails with Unhandled Exception 4 on armcl 1.12-dev (v1.12-dev.4-3-gdd5622e9), but does not fail in release version v1.11.5 </div><div class=""><br class=""></div><div class="">* If I put a lock around the garbage generation (just a make-string), to exercise locking in threads, in v1.11.5 it fails with <span class="Apple-tab-span" style="white-space: pre;"> </span>“Current process #<PROCESS Reader 4(26) [Active] #x150D335E> does not own lock #<RECURSIVE-LOCK "glock" [ptr @ #x76105C60] #x150BB0D6> in CCL::%UNLOCK-RECURSIVE-LOCK-OBJECT"</div><div class=""><br class=""></div><div class="">Is it possible that imperfect locking (race condition? non atomicity?) in the armcl implementation causes bug 1257, mimicking a GC bug? </div><div class=""><br class=""></div><div class="">Regards,</div><div class="">-John</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>