Re: srfi-18 requirements

[Neil Jerram]

"Julian Graham" <address@hidden> 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