Problem with SRFI 18: Multithreading support

Hello SISC users,

I'm wondering whether I have encountered a bug in the SRFI 18
implementation of SISC, or whether my own understanding of the SRFI is
erroneous.

Here is what I'm doing:

SISC (1.16.6)
#;> (require-extension (srfi 18))
#;> (define m (make-mutex))
#;> (mutex-state m)
not-abandoned
#;> (thread-start! (make-thread (lambda () (display (mutex-lock! m #f #f)))))
#;>(thread-start!
 (make-thread
  (lambda ()
    (display (mutex-lock! m #f #f))
    (thread-sleep! 10)
    (display (mutex-lock! m #f #f)))))
#t#<thread>
#;> (mutex-state m)
not-owned
#;> (mutex-unlock! m)
#t
#;> (mutex-state m)
not-abandoned
#;> (mutex-lock! m 5 #f)
#f                                                              (after
5 seconds)
#t                                                              (after
10 seconds)
(mutex-state m)
not-owned
#;>


I expected the MUTEX-LOCK! application on the main thread to succeed
in obtaining a lock, since the mutex is reported to be
"unlocked/not-abandoned."  It seems to me that MUTEX-UNLOCK! is
somehow making the mutex "belong" to the spawned thread, since the
later does succeed in obtaining the lock again.

Am I on error, or is this a bug?

Thanks for your help!

Best Regards,

Victor Rodriguez.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/