[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: srfi-18 requirements
Re: srfi-18 requirements
Wed, 26 Mar 2008 11:55:54 -0400
> 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)
...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
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...)