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?