From llmjjmll at gmail.com  Wed May  2 15:15:21 2012
From: llmjjmll at gmail.com (James M. Lawrence)
Date: Wed, 2 May 2012 11:15:21 -0400
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <1334676101.15697.18.camel@cathai>
References: <1334676101.15697.18.camel@cathai>
Message-ID: <CAAmBhX9rjheLC1-57=syfZtKMPKMEqUv+7Z8cuB_XvuOtS_REg@mail.gmail.com>

On Tue, Apr 17, 2012 at 11:21 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
> They're an ugly hack, as described their inventor David Butenhof
> (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by
> all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive
> lock, but it's not a posix recursive lock), so I was thinking of making
> a 1.0 release in which to remove them altogether.
>
> What do you think ?

I currently use a recursive lock for debug logging. In the past I
wrapped *debugger-hook* with a recursive lock in order to avoid
multiple simultaneous debugger popups. Both are cases of throwaway
code.

David Butenhof does mention that recursive locks "can be a great tool"
as long as they are properly understood as a temporary measure. That's
how I use them, and others may as well. Yes, they are a hack, but they
are a convenient hack.

If recursive locks are removed then I would expect people to write
their own half-ass implementations, as I would do for my debug logger.
I agree that using them in a non-temporary context may constitute poor
design, however that does not imply that they should be removed.

Perhaps adding a note to the documentation regarding the hackiness of
recursive locks (and/or even linking to the Butenhof post) would
suffice in lieu of outright deletion?

If you do decide to remove them, consider issuing deprecation warnings
in the next release (or longer) before the actual removal. There is at
least one logging library in quicklisp which uses a recursive lock. I
assume other projects out there would be broken as well.



From sionescu at cddr.org  Wed May  2 15:27:51 2012
From: sionescu at cddr.org (Stelian Ionescu)
Date: Wed, 02 May 2012 17:27:51 +0200
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <CAAmBhX9rjheLC1-57=syfZtKMPKMEqUv+7Z8cuB_XvuOtS_REg@mail.gmail.com>
References: <1334676101.15697.18.camel@cathai>
	<CAAmBhX9rjheLC1-57=syfZtKMPKMEqUv+7Z8cuB_XvuOtS_REg@mail.gmail.com>
Message-ID: <1335972471.17798.3.camel@cathai>

On Wed, 2012-05-02 at 11:15 -0400, James M. Lawrence wrote:
> On Tue, Apr 17, 2012 at 11:21 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
> > They're an ugly hack, as described their inventor David Butenhof
> > (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by
> > all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive
> > lock, but it's not a posix recursive lock), so I was thinking of making
> > a 1.0 release in which to remove them altogether.
> >
> > What do you think ?
> 
> I currently use a recursive lock for debug logging. In the past I
> wrapped *debugger-hook* with a recursive lock in order to avoid
> multiple simultaneous debugger popups. Both are cases of throwaway
> code.
> 
> David Butenhof does mention that recursive locks "can be a great tool"
> as long as they are properly understood as a temporary measure. That's
> how I use them, and others may as well. Yes, they are a hack, but they
> are a convenient hack.
> 
> If recursive locks are removed then I would expect people to write
> their own half-ass implementations, as I would do for my debug logger.
> I agree that using them in a non-temporary context may constitute poor
> design, however that does not imply that they should be removed.
> 
> Perhaps adding a note to the documentation regarding the hackiness of
> recursive locks (and/or even linking to the Butenhof post) would
> suffice in lieu of outright deletion?
> 
> If you do decide to remove them, consider issuing deprecation warnings
> in the next release (or longer) before the actual removal. There is at
> least one logging library in quicklisp which uses a recursive lock. I
> assume other projects out there would be broken as well.

Which one ? Such library is broken because few CL implementations
actually have recursive locks

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20120502/27bf32fe/attachment.sig>

From llmjjmll at gmail.com  Wed May  2 17:13:57 2012
From: llmjjmll at gmail.com (James M. Lawrence)
Date: Wed, 2 May 2012 13:13:57 -0400
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <1335972471.17798.3.camel@cathai>
References: <1334676101.15697.18.camel@cathai>
	<CAAmBhX9rjheLC1-57=syfZtKMPKMEqUv+7Z8cuB_XvuOtS_REg@mail.gmail.com>
	<1335972471.17798.3.camel@cathai>
Message-ID: <CAAmBhX9eXYSzCURe-LMMJ0jNkXGY4UmEKgFhnX+BAius_juVuw@mail.gmail.com>

On Wed, May 2, 2012 at 11:27 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
> On Wed, 2012-05-02 at 11:15 -0400, James M. Lawrence wrote:
>> On Tue, Apr 17, 2012 at 11:21 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
>> > They're an ugly hack, as described their inventor David Butenhof
>> > (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by
>> > all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive
>> > lock, but it's not a posix recursive lock), so I was thinking of making
>> > a 1.0 release in which to remove them altogether.
>> >
>> > What do you think ?
>>
>> I currently use a recursive lock for debug logging. In the past I
>> wrapped *debugger-hook* with a recursive lock in order to avoid
>> multiple simultaneous debugger popups. Both are cases of throwaway
>> code.
>>
>> David Butenhof does mention that recursive locks "can be a great tool"
>> as long as they are properly understood as a temporary measure. That's
>> how I use them, and others may as well. Yes, they are a hack, but they
>> are a convenient hack.
>>
>> If recursive locks are removed then I would expect people to write
>> their own half-ass implementations, as I would do for my debug logger.
>> I agree that using them in a non-temporary context may constitute poor
>> design, however that does not imply that they should be removed.
>>
>> Perhaps adding a note to the documentation regarding the hackiness of
>> recursive locks (and/or even linking to the Butenhof post) would
>> suffice in lieu of outright deletion?
>>
>> If you do decide to remove them, consider issuing deprecation warnings
>> in the next release (or longer) before the actual removal. There is at
>> least one logging library in quicklisp which uses a recursive lock. I
>> assume other projects out there would be broken as well.
>
> Which one ? Such library is broken because few CL implementations
> actually have recursive locks

log4cl, released a few months ago.

You mentioned that Clozure does not support recursive locks. The funny
thing about Clozure is that ccl:make-lock actually returns a recursive
lock. So bt:make-recursive-lock is, through coincidence, providing a
recursive lock by calling ccl:make-lock.

Thus users may be fooled into thinking bordeaux-threads is making some
guarantee when it hasn't. The behavior of Clozure may change in the
future, for all we know.

The best of both worlds is to move recursive locks to the
introspection/debugging section of the documentation. Recursive locks
would be there as convenience for the use case I mentioned, while
users would be made aware that they are not dependable across
implementations.



From sionescu at cddr.org  Wed May  2 19:09:23 2012
From: sionescu at cddr.org (Stelian Ionescu)
Date: Wed, 02 May 2012 21:09:23 +0200
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <CAAmBhX9eXYSzCURe-LMMJ0jNkXGY4UmEKgFhnX+BAius_juVuw@mail.gmail.com>
References: <1334676101.15697.18.camel@cathai>
	<CAAmBhX9rjheLC1-57=syfZtKMPKMEqUv+7Z8cuB_XvuOtS_REg@mail.gmail.com>
	<1335972471.17798.3.camel@cathai>
	<CAAmBhX9eXYSzCURe-LMMJ0jNkXGY4UmEKgFhnX+BAius_juVuw@mail.gmail.com>
Message-ID: <1335985763.17798.5.camel@cathai>

On Wed, 2012-05-02 at 13:13 -0400, James M. Lawrence wrote:
> On Wed, May 2, 2012 at 11:27 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
> > On Wed, 2012-05-02 at 11:15 -0400, James M. Lawrence wrote:
> >> On Tue, Apr 17, 2012 at 11:21 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
> >> > They're an ugly hack, as described their inventor David Butenhof
> >> > (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by
> >> > all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive
> >> > lock, but it's not a posix recursive lock), so I was thinking of making
> >> > a 1.0 release in which to remove them altogether.
> >> >
> >> > What do you think ?
> >>
> >> I currently use a recursive lock for debug logging. In the past I
> >> wrapped *debugger-hook* with a recursive lock in order to avoid
> >> multiple simultaneous debugger popups. Both are cases of throwaway
> >> code.
> >>
> >> David Butenhof does mention that recursive locks "can be a great tool"
> >> as long as they are properly understood as a temporary measure. That's
> >> how I use them, and others may as well. Yes, they are a hack, but they
> >> are a convenient hack.
> >>
> >> If recursive locks are removed then I would expect people to write
> >> their own half-ass implementations, as I would do for my debug logger.
> >> I agree that using them in a non-temporary context may constitute poor
> >> design, however that does not imply that they should be removed.
> >>
> >> Perhaps adding a note to the documentation regarding the hackiness of
> >> recursive locks (and/or even linking to the Butenhof post) would
> >> suffice in lieu of outright deletion?
> >>
> >> If you do decide to remove them, consider issuing deprecation warnings
> >> in the next release (or longer) before the actual removal. There is at
> >> least one logging library in quicklisp which uses a recursive lock. I
> >> assume other projects out there would be broken as well.
> >
> > Which one ? Such library is broken because few CL implementations
> > actually have recursive locks
> 
> log4cl, released a few months ago.
> 
> You mentioned that Clozure does not support recursive locks. The funny
> thing about Clozure is that ccl:make-lock actually returns a recursive
> lock.

Indeed I was fooled by that. Good to know, this is a excellent reason
not to ever use Clozure

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20120502/d3a3fd1d/attachment.sig>

From lisp.linux at gmail.com  Wed May  2 19:10:39 2012
From: lisp.linux at gmail.com (Antony)
Date: Wed, 02 May 2012 12:10:39 -0700
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <1334676101.15697.18.camel@cathai>
References: <1334676101.15697.18.camel@cathai>
Message-ID: <4FA186AF.60700@gmail.com>

On 4/17/2012 8:21 AM, Stelian Ionescu wrote:
> They're an ugly hack, as described their inventor David Butenhof
> (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by
> all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive
> lock, but it's not a posix recursive lock), so I was thinking of making
> a 1.0 release in which to remove them altogether.
>
> What do you think ?
>
>
I use CCL at the moment
Not having recursive locks makes locking code more complicated. With 
recursive locks I only need to think about ensuring order when more than 
one lock is involved.  Without recursive lock, every possible call path 
to every lock needs to be thought through.

I confirmed that CCL does support recursive locking
http://clozure.com/pipermail/openmcl-devel/2012-May/013536.html

FWIW  for .net
   http://msdn.microsoft.com/en-us/library/de0542zz%28v=vs.71%29.aspx
   "It is legal for the same thread to invoke Enter more than once 
without it blocking"

   for java  
http://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html
   "a thread can acquire a lock that it already owns"  (so I assume ABCL 
does recursive locks)

I read the message by Dave Butenhof
  http://groups.google.com/group/comp.programming.threads/msg/d835f2f6ef8aed99?hl=en&pli=1
that I think was pointed as the logic behind getting rid of recursive 
mutexes in bordeaux.
I did a basic read. I am not an expert. I came to the conclusion, that 
he is confounding having a short duration hold on a lock with having a 
single lock request within a thread. That is, he is using the call stack 
depth to imply longer code, or in other words he is coming from the 
world of large functions. Even though those two things correlate often, 
that does not meean I can not have a couple of small functions each 
containing a with-... macro that does locking and then not have to 
bother with which exact combinations of mutual calls can happen among them.

While I agree it would be good if my code worked without recursive 
locks, I think I'd prefer having recursive locks. I do think of keeping 
locked duration short, but I don't scratch my head around call sequences 
within a thread requesting the same lock.

Unlike any other aspect of CL, threading in CL is very immature and 
removing this support is not going to help.
I hope the decision to remove support will be reconsidered and some 
alternative like runtime/compile error will be implemented for 
implementations that don't support recursive locks..


-Antony




From vsedach at gmail.com  Wed May  2 20:57:44 2012
From: vsedach at gmail.com (Vladimir Sedach)
Date: Wed, 2 May 2012 16:57:44 -0400
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <4FA186AF.60700@gmail.com>
References: <1334676101.15697.18.camel@cathai>
	<4FA186AF.60700@gmail.com>
Message-ID: <CAD_S9D-4HD_7u3_qa+q7gYZ=vyrbGLTs_VqhaNNXytfTizzTRg@mail.gmail.com>

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.

Vladimir

On Wed, May 2, 2012 at 3:10 PM, Antony <lisp.linux at gmail.com> wrote:
> On 4/17/2012 8:21 AM, Stelian Ionescu wrote:
>>
>> They're an ugly hack, as described their inventor David Butenhof
>> (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by
>> all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive
>> lock, but it's not a posix recursive lock), so I was thinking of making
>> a 1.0 release in which to remove them altogether.
>>
>> What do you think ?
>>
>>
> I use CCL at the moment
> Not having recursive locks makes locking code more complicated. With
> recursive locks I only need to think about ensuring order when more than one
> lock is involved. ?Without recursive lock, every possible call path to every
> lock needs to be thought through.
>
> I confirmed that CCL does support recursive locking
> http://clozure.com/pipermail/openmcl-devel/2012-May/013536.html
>
> FWIW ?for .net
> ?http://msdn.microsoft.com/en-us/library/de0542zz%28v=vs.71%29.aspx
> ?"It is legal for the same thread to invoke Enter more than once without it
> blocking"
>
> ?for java
> ?http://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html
> ?"a thread can acquire a lock that it already owns" ?(so I assume ABCL does
> recursive locks)
>
> I read the message by Dave Butenhof
> ?http://groups.google.com/group/comp.programming.threads/msg/d835f2f6ef8aed99?hl=en&pli=1
> that I think was pointed as the logic behind getting rid of recursive
> mutexes in bordeaux.
> I did a basic read. I am not an expert. I came to the conclusion, that he is
> confounding having a short duration hold on a lock with having a single lock
> request within a thread. That is, he is using the call stack depth to imply
> longer code, or in other words he is coming from the world of large
> functions. Even though those two things correlate often, that does not meean
> I can not have a couple of small functions each containing a with-... macro
> that does locking and then not have to bother with which exact combinations
> of mutual calls can happen among them.
>
> While I agree it would be good if my code worked without recursive locks, I
> think I'd prefer having recursive locks. I do think of keeping locked
> duration short, but I don't scratch my head around call sequences within a
> thread requesting the same lock.
>
> Unlike any other aspect of CL, threading in CL is very immature and removing
> this support is not going to help.
> I hope the decision to remove support will be reconsidered and some
> alternative like runtime/compile error will be implemented for
> implementations that don't support recursive locks..
>
>
> -Antony
>
>
>
> _______________________________________________
> Bordeaux-threads-devel mailing list
> Bordeaux-threads-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel



From jean.claude.beaudoin at gmail.com  Thu May  3 02:30:25 2012
From: jean.claude.beaudoin at gmail.com (Jean-Claude Beaudoin)
Date: Wed, 02 May 2012 22:30:25 -0400
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <CAD_S9D-4HD_7u3_qa+q7gYZ=vyrbGLTs_VqhaNNXytfTizzTRg@mail.gmail.com>
References: <1334676101.15697.18.camel@cathai>	<4FA186AF.60700@gmail.com>
	<CAD_S9D-4HD_7u3_qa+q7gYZ=vyrbGLTs_VqhaNNXytfTizzTRg@mail.gmail.com>
Message-ID: <jnsrc6$aod$1@dough.gmane.org>

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?




From llmjjmll at gmail.com  Thu May  3 04:28:32 2012
From: llmjjmll at gmail.com (James M. Lawrence)
Date: Thu, 3 May 2012 00:28:32 -0400
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <CAD_S9D-4HD_7u3_qa+q7gYZ=vyrbGLTs_VqhaNNXytfTizzTRg@mail.gmail.com>
References: <1334676101.15697.18.camel@cathai> <4FA186AF.60700@gmail.com>
	<CAD_S9D-4HD_7u3_qa+q7gYZ=vyrbGLTs_VqhaNNXytfTizzTRg@mail.gmail.com>
Message-ID: <CAAmBhX96AvYXrsLmv_DSsKTp-D7QWE4_vj8uL=8OTkukV89nFQ@mail.gmail.com>

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.



From leslie.polzer at gmx.net  Thu May  3 06:28:30 2012
From: leslie.polzer at gmx.net (Leslie P. Polzer)
Date: Thu, 03 May 2012 08:28:30 +0200
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
Message-ID: <20120503062830.284070@gmx.net>

Stelian Ionescu wrote:
> They're an ugly hack, as described their inventor David Butenhof
> (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by
> all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive
> lock, but it's not a posix recursive lock), so I was thinking of making
> a 1.0 release in which to remove them altogether.
>
> What do you think ?

I think it's a bad idea. For me rapid prototyping is an important
part of Lisp, and recursive locks support this approach. What
Butenhof basically holds against them is that you're not looking
at your threading code closely enough. But in the beginning stages
of a project I actually might not want to do that. Doing away
with them would be premature optimization. Add a note of caution
to the docstring if you're that concerned, but don't remove them.

  Leslie
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de



From lisp.linux at gmail.com  Thu May  3 07:00:37 2012
From: lisp.linux at gmail.com (Antony)
Date: Thu, 03 May 2012 00:00:37 -0700
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <CAD_S9D-4HD_7u3_qa+q7gYZ=vyrbGLTs_VqhaNNXytfTizzTRg@mail.gmail.com>
References: <1334676101.15697.18.camel@cathai> <4FA186AF.60700@gmail.com>
	<CAD_S9D-4HD_7u3_qa+q7gYZ=vyrbGLTs_VqhaNNXytfTizzTRg@mail.gmail.com>
Message-ID: <4FA22D15.4010305@gmail.com>

On 5/2/2012 1:57 PM, Vladimir Sedach wrote:
While what you say below I am sure is true, is it good enough to say 
recursive locking should be removed?
Trying to use the same mutex for normal locking and again as part of 
condition variable structure I think is breaking the abstraction of 
condition variable.
Also, if someone writes code that recursively locks to control access to 
a resource and then tries to do signalling deep in the call stack using 
that same mutex combined with a condition var, that's just bad code. 
Saying we shouldn't have recursive mutexes because of that is like 
saying we shouldn't have threads cause they can corrupt each others 
variables.

I do like this mail thread since I think it's good to discuss this. 
Sorry, I did not respond early enough.

-Antony

> 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.
>
> Vladimir
>
>




From lisp.linux at gmail.com  Thu May  3 07:07:01 2012
From: lisp.linux at gmail.com (Antony)
Date: Thu, 03 May 2012 00:07:01 -0700
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
In-Reply-To: <20120503062830.284070@gmx.net>
References: <20120503062830.284070@gmx.net>
Message-ID: <4FA22E95.7030100@gmail.com>

On 5/2/2012 11:28 PM, Leslie P. Polzer wrote:
> Stelian Ionescu wrote:
>> They're an ugly hack, as described their inventor David Butenhof
>> (http://tinyurl.com/butenhof-recursive-mutexes) and aren't supported by
>> all lisps: Allegro, Clozure, CMUCL, SBCL(it has a kind of recursive
>> lock, but it's not a posix recursive lock), so I was thinking of making
>> a 1.0 release in which to remove them altogether.
>>
>> What do you think ?
> I think it's a bad idea. For me rapid prototyping is an important
> part of Lisp, and recursive locks support this approach. What
> Butenhof basically holds against them is that you're not looking
> at your threading code closely enough. But in the beginning stages
> of a project I actually might not want to do that. Doing away
> with them would be premature optimization. Add a note of caution
> to the docstring if you're that concerned, but don't remove them.
>
>    Leslie
I had very similar thought. I think in general the problem is lots of 
people try to write up software engineering rules based on the end 
product (that is the code as it looks while being shipped). Whereas the 
rules/guidelines should be done based on the process that gets you from 
nothing to the end product. This is true no matter how rapid (or not)  
the methodology is.

-Antony



From avodonosov at yandex.ru  Thu May 10 10:11:23 2012
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Thu, 10 May 2012 14:11:23 +0400
Subject: [Bordeaux-threads-devel] Deprecating recursive locks
Message-ID: <75121336644683@web9f.yandex.ru>

18.04.2012, 01:48, "Anton Vodonosov" <avodonosov at yandex.ru>:

> ?If the public API is changed in a not-backward-compatible way, I would
> ?suggest to release new ASDF system (bordeaux-threads2), and
> ?leave the old version available in quicklisp forever.
>
> ?People who are ready to use new version, just add bordeaux-thread2
> ?into their ASDF dependency. Others are able to use old version.
>
> ?This is a good practice. And it costs nothing.
>
> ?Some links on this subject:
> ?http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-libraries
> ?http://semver.org/

How to handle backward compatibility of bordeaux-threads if the API is changed
is up to the maintainer.

Still, I think the approach I suggest may be a good solution for lisp libraries
evolution, and I would like to present some arguments to support this approach.

18.04.2012, 08:15, "Attila Lendvai" <attila.lendvai at gmail.com>:

> ?IMHO it's not a good practice and it does cost complexity/noise.
>
> ?you lose the clarity around the digital representation(s) of the
> ?identity of the library. there's only one b-t library, and the fact
> ?that it has changed in a way that made it incompatible with something
> ?else does not change its identity.

No, I only suggest to create separate ASDF system and package
for new version of the API. It is not uncommon for lisp project to
have several ASDF systems and packages. Should these packages
be delivered in the same tarball? They may, but non necessary.
(depending what is more convenient for the maintainers).

As for the library identity, it can remain the same. What is meant by
the library identity and how it is used? Project home page will remain the same,
for example, mailing list is the same. I.e. it still remains the same
project.

If we had two bordeaux-threads versions, one with recursive
locks, and one without, why not allow suers to name exactly what
API their programs need.

22.04.2012, 18:41, "Stelian Ionescu" <sionescu at cddr.org>:

> ?On Wed, 2012-04-18 at 01:48 +0400, Anton Vodonosov wrote:
>> ??Some links on this subject:
>> ??http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-libraries
> ?That post contains a good analysis of the problem, but then gives the
> ?worst possible advice to solve it

Why?

At least, this statement is to strong - one can easily create 10 advices worse than
the post gives :)

If speak seriously, in my opinion referring major version, i.e. specific API, is a good advice.

>> ??http://semver.org/
> ?Point 5 says "Major version zero (0.y.z) is for initial development.
> ?Anything may change at any time. The public API should not be considered
> ?stable". So no problem there

I do not mean we have problem because we contradict some text. I mean that
if we have practical problem that N systems will stop to compile after the
b-t API changes, leaving the old "frozen" version of API available for these
libraries may be a good practical solution for this problem.

And the approach of distinguishing changes which modify public API
from ones which do not modify the public API is not new. Thus the links,
and more examples may be found.

IMHO this approach frees the library API to evolve easily, without requiring
efforts from the library maintainers, and at the same time not breaking any
other systems.

Best regards,
- Anton