"Julian Graham" <[EMAIL PROTECTED]> writes:
>> 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.
OK, let's enable those then.
> ...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)
I believe that this issue disappears if we conclude that we do in fact
need to represent locked/not-owned somehow in the core - and I'm now
inclined to that conclusion - see below.
For the record, though, and in case we do not reach that conclusion,
here's what I wrote when considering this scenario on its own:
============ assuming locked/not-owned is NOT in core =============
Hmmm, tricky.....
> 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...)
I agree that we want co-existence in some sense, but I'm not sure that
sense extends to mixing core and SRFI-18 API calls for the same
mutex. I'm struggling right now to explain exactly what I mean - but
my intuition is that the use case above is going beyond
reasonableness, and so we could reasonably say that the result of
mutex-state would be undefined in this case.
(In practice, of course, it will probably be locked/not-owned.)
What do you think?
============ assuming locked/not-owned is NOT in core =============
> 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'.
I think there are two separate things here.
1. Calling lock-mutex with a thread parameter different from the
calling thread, and which isn't #f. I believe this should be a core
feature (as well as a SRFI-18 one), and it had completely escaped my
notice that this detail had evaporated from your patches. I believe
you implemented this originally, then removed it following my attempt
to draw a line between core stuff and SRFI-18 stuff - so I guess you
thought that was one of the implications of what I wrote; sorry about
that. Would it be easy at this point to reinstate this?
2. Calling lock-mutex with thread parameter #f, such as to produce the
SRFI-18 locked/not-owned state. My previous pure Scheme suggestion
for locked/not-owned was based on my statement that:
"AFAICS, SRFI-18 specifies nothing at all (apart from mutex-state
itself) which depends on the difference between locked/owned and
locked/not-owned. Therefore I don't think we should support this
state in the core."
But I see now that that statement is wrong - because thread exit may
cause a locked/owned mutex to transition to unlocked/abandoned, but
will have no effect on a locked/not-owned mutex.
So it now looks like we do need locked/not-owned in the core after
all.
In terms of the C/Scheme boundary, one possible representation of this
would be to introduce a mutex-locked? primitive, which is significant
when mutex-owner returns #f, and distinguishes between the normal
unlocked state and locked/not-owned. Then I think SRFI-18 mutex state
could be written as
(define (mutex-state m)
(let ((owner (mutex-owner m)))
(if owner
(if (thread-exited? owner)
'abandoned
owner)
(if (mutex-locked? m)
'not-owned
'not-abandoned))))
That would avoid reintroducing a detail that I disliked in the
original patch, namely the definition of the SRFI-18 state symbols in
the C code.
What do you think?
Regards,
Neil
