Re: srfi-18 requirements

[Julian Graham]

>  I also see no problem - in API terms - with un-ifdefing
>  scm_mutex_owner (and scm_mutex_level, while we're there).  Could you
>  just review, though, whether you're happy with their implementation?
>  In particular, should these functions lock and unlock m->lock?

Given that SCM is supposed to be more or less opaque, I think it's
probably safer to at least lock within scm_mutex_owner.  Otherwise,
I'm happy with those C implementations.

...Except that I've run into a few more snags related to ownership
when it comes to mixing of core calls and SRFI-18 calls --
specifically, notifying the SRFI-18 implementation of changes to
ownership that occur as a result of locking / unlocking a mutex from
the core code.  For example, what should be the result of
`mutex-state' after the following series of expressions?


(use-modules (srfi srfi-18))

(define m (make-mutex))
(mutex-lock! m (current-time) #f)
(unlock-mutex m)
(lock-mutex m)


...according to the pure Scheme ownership implementation you suggested
back in January, locking a mutex via SRFI-18 `mutex-lock!' with an
explicit non-current-thread owner would set an object property on the
mutex, but if core code that is unaware of the SRFI-18 implementation
details unlocks and relocks the mutex, the object property gets out of
sync in a way that I don't think is possible to detect.  (Or is this
not a valid use case?  My understanding based on our previous
conversations is that we want core and SRFI-18 code to be able to
co-exist as much as possible...)

There's a related problem with SRFI-18's requirement that threads
waiting on mutexes be notified when the owner thread exits -- the core
implementation now notifies waiters when the owner exits, but as far
as the core is concerned, the owner will always be the thread that
called `lock-mutex'.

A possible solution that comes to mind is making the core aware of any
object properties that SRFI-18 defines, but that's not optimal from a
design point of view.


>  But that's spec vs. implementation.  I'd tend to give the spec writers
>  the benefit of the doubt here, i.e. to assume that they had reasonable
>  implementations in mind where it would be a performance hit.
>
>  (And of course, the pthreads point/argument doesn't transfer in detail
>  across to Guile's API, because our mutexes offer a lot more features
>  than the base pthreads mutexes.)

Certainly -- I was just looking for reasons that `mutex-owner'
shouldn't be enabled.  (My expectation was that the pthreads spec
would reject features like that on the basis that "good"
multi-threaded code shouldn't need to query things like mutex
ownership, but I didn't see any objections on that front...)


Regards,
Julian