> 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?
Yes. For C, though, how do you want to manage passing these flags? I imagine the primitive should be named something like scm_make_mutex_with_options (or _with_flags), and we could either require two arguments (each being a symbol option as described below or SCM_UNDEFINED) or have it take a list containing an arbitrary number of symbol options to allow us to extend its behavior as necessary. I didn't get a strong sense of established precedent looking at Guile's C API; I'm kind of leaning towards the list approach right now. > > 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. Cool -- I'll set up make-mutex for Scheme, and for C as described above. Let me know if that's not okay. Regards, Julian
