[Bordeaux-threads-devel] Deprecating recursive locks

[James M. Lawrence]

On Wed, May 2, 2012 at 4:57 PM, Vladimir Sedach <vsedach at gmail.com> 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.

Ensuring portability seems outside the scope of bordeaux. Take the
example of Clozure, where all locks are recursive locks. Is it
bordeaux's responsibility to ensure that the thing returned by
make-lock is not locked twice?

Indeed bordeaux includes functions which are explicitly unportable.
The issue you mention with condition variables is a good reason to
update the documentation on recursive locks. Why not simply note the
behavior as unportable, as with destroy-thread?

Nobody is arguing to remove the five functions which "are not advised
to be called from normal user code". They are kept because they are
useful. The same is true of recursive locks, which for example are
convenient for logging. Isn't that reason enough to keep them?

It appears that the 11 implementations covered by bordeaux all support
recursive locks except Macintosh CL. All locking is recursive in
Clozure and CMUCL. Allegro has

  (mp:with-process-lock (lock :norecursive nil) ...).

I've had no trouble with SBCL's non-POSIX recursive lock, though I
only use it for logging.