[Bordeaux-threads-devel] Deprecating recursive locks

[Jean-Claude Beaudoin]

Vladimir Sedach wrote:
> Another argument against recursive locks that hasn't come up yet is
> that they fail very badly when used with condition variables. I think
> the fact that recursive locks aren't supported by most implementations
> plus the fact that they behave differently wrt condition variables on
> different implementations and operating systems are very good
> arguments for leaving recursive locks out of a portable threading
> library.
> 

I had not paid much attention to this issue until now but this
last argument about condition variables just made such that
the default behavior of #'mt:make-lock of MKCL will be from now on
to produce a non-recursive lock even if this is a break with
the behavior inherited from ECL. This starting with MKCL 1.1.0 RC2.
If you want recursive locks you will have to request it
explicitly with (make-lock :recursive t).

There may be some protest against this change but the strength
of the "condition variable" point will override them.

Cheers,

Jean-Claude Beaudoin

P.S.: SLIME blew up big time on this change. I had to force
swank-backend:make-lock back into producing recursive locks
in order to prevent it from crashing. That's bad...

I am also considering whether #'mt:condition-wait
should emit a warning if it ever receives a recursive lock.
(Even more so if the recursive lock has a count above 1!)
What do you think of this?