Re: srfi-18 requirements

[Neil Jerram]

"Julian Graham" <address@hidden> writes:

>>  Sorry for missing this before.  The SRFI-18 semantics are really
>>  interesting, but I think we need to preserve the existing semantics
>>  too for back-compatibility.
>
> Sure, fair enough.
>
>
>>  I guess that means that scm_unlock_mutex_timed will need to take
>>  another optional parameter (or two) indicating whether
>>
>>  - it is an error to unlock an unlocked mutex (default yes, but SRFI-18
>>   will pass "no")
>>
>>  - it is an error to unlock a mutex owned by another thread (default
>>   yes, SRFI-18 will pass "no").
>>
>>  Can you propose a representation for this?
>
> Well, this could be down with an entirely separate primitive -- that
> is, we could add something with a name like scm_make_permissive_mutex
> that initializes the fat_mutex struct with a couple of new flags.
> That wouldn't be strictly compatible with SRFI-18, since SRFI-18
> `mutex-unlock!' accessing regular mutexes through Guile's primitives
> could cause errors to be signaled, but it actually might make more
> sense than passing flags to the unlock call, since I would think users
> would want consistent behavior from their mutexes, no matter which
> functions were used to manipulate them.

Agreed, that's a nice solution.  The matter of whether a mutex can be
unlocked by another thread will depend on an application's design for
how it uses that mutex, and it feels right for the application to
declare this when the mutex is created, instead of on every unlock
call.

On the Scheme level, I think the call can still be `make-mutex', with
optional flag args - is that right?

> Actually, I just remembered a fairly elegant approach that seems to be
> used in other parts of the Guile API -- these optional arguments could
> be specified as symbols: 'unlock-if-unowned and
> 'unlock-if-owned-by-other, say.  Let me know what you'd prefer.

This is still an interesting question, but now for `make-mutex'
instead of for `unlock-mutex'.  Personally I like the symbol approach,
because (in comparison with a sequence of #t and #f) it will make the
code easier to understand at the point of the call, and also because
the #t/#f approach requires remembering the parameter ordering.

>>  Is it possible to reorganize the relevant code a bit, so that
>>  scm_unlock_mutex_timed (mx, cv, 0) does not lock and immediately
>>  unlock the mutex after the cond var has been signalled?
>
> Certainly.  It'll be in the next version of the patch.

Looking forward to it!

> Regards,
> Julian

Regards,
  Neil