> 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
