#238 SRFI-18 mutexes are not reentrant

open
nobody
None
5
2007-10-25
2007-10-25
No

SRFI-18 gives an alternate definition for thread-sleep! as follows:

(define (sleep! timeout)
(let ((m (make-mutex)))
(mutex-lock! m #f #f)
(mutex-lock! m timeout #f)))

This doesn't work in SISC, because SISC mutexes are reentrant.

So either SRFI-18 is underspecified/ambiguous (whether mutexes are reentrant is not explicitly stated, although from the above example they implicitly are not) or SISC does not in fact support SRFI-18.

Discussion

  • Nobody/Anonymous

    from srfi-18

    "The mutex primitives specified in this SRFI do not implement "recursive" mutex semantics; an attempt to lock a mutex that is locked implies that the current thread must wait even if the mutex is owned by the current thread (this can lead to a deadlock if no other thread unlocks the mutex)."

    under mutex-lock

    "It is not an error if the mutex is owned by the current thread (but the current thread will have to wait). "

    i agree with the submitter that srfi-18 mutexes are not reentrant.

    the srfi notes this method of adapting to reentrant locks:

    (define (mutex-lock-recursively! mutex)
    (if (eq? (mutex-state mutex) (current-thread))
    (let ((n (mutex-specific mutex)))
    (mutex-specific-set! mutex (+ n 1)))
    (begin
    (mutex-lock! mutex)
    (mutex-specific-set! mutex 0))))

    (define (mutex-unlock-recursively! mutex)
    (let ((n (mutex-specific mutex)))
    (if (= n 0)
    (mutex-unlock! mutex)
    (mutex-specific-set! mutex (- n 1)))))

    now, looking at the implementation in /src/sisc/modules/Threads.java(mutex.lock and mutex.acquire), one can observe that sisc relies on java's implementation of locks and synchronized objects, which are reentrant.

    i don't have a clear implementation in mind right now, but a scheme for introducing another layer of access, one for getting permission to unlock and one for performing unlock might allow the simulation of non-reentrant locks with a system using reentrant locks.

    finally, i personally would tend to favor the systems current behavior. my rationale would be most people who come to a scheme-on-jvm system would assume a java tendency in its synchronization system. might also help with interoperability between native code that uses threads and scheme code that uses sisc threading to have same locking behavior, though i'm not sure whether that is supported/encouraged with sisc.

     
  • Nobody/Anonymous

    -kanishka

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks