Mark Evenson | 1 Mar 16:18 2011
Picon

Re: [Updated3] Patch for ABCL against BORDEAUX-THREADS HEAD

After critique from Stellian, I have [successfully brought my patches in 
alignment with BORDEAUX-THREADS GIT head][1].

Please review this for inclusion.

[1]: http://slack.net/~evenson/abcl/bordeaux-threads-abcl-20110301a.diff

--

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
Martin Simmons | 2 Mar 20:50 2011

Re: [Updated3] Patch for ABCL against BORDEAUX-THREADS HEAD

>>>>> On Tue, 01 Mar 2011 16:18:35 +0100, Mark Evenson said:
> 
> After critique from Stellian, I have [successfully brought my patches in 
> alignment with BORDEAUX-THREADS GIT head][1].
> 
> Please review this for inclusion.
> 
> [1]: http://slack.net/~evenson/abcl/bordeaux-threads-abcl-20110301a.diff

I think that the implementation of condition-wait has some major problems:

1) If no other threads are trying to claim the lock, then condition-wait will
return immediately rather than waiting.

2) If two threads are waiting in condition-wait and two other threads call
condition-notify, then it is possible that only one thread will return from
condition-wait because the call to acquire-lock in one of them might return
nil causing it to wait again.

3) If condition-notify is called by one thread when a waiting thread is just
about to enter the threads:synchronized-on form (but before it gets
synchronized), then the notify will be lost.  This happens because the
underlying threading primitives have no "memory" of calls to notify when
nothing it waiting (which is also the expected semantics for POSIX condition
variables BTW).

Also, I think condition-notify should be using threads:object-notify rather
than threads:object-notify-all.

--

-- 
(Continue reading)

Jeff Cunningham | 11 Mar 01:40 2011

thread-join vs join-thread in API

> Hi.
>
> New to the list. I noticed the Trac API gives the function name as
> THREAD-JOIN, which doesn't exist in bordeaux-threads under SBCL. However
> JOIN-THREAD does. Should one or the other be changed?
>
> Regards,
> Jeff Cunningham
Mark Evenson | 18 Mar 08:50 2011
Picon

Re: [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD

On 3/2/11 8:50 PM, Martin Simmons wrote:

> I think that the implementation of condition-wait has some major problems:

Thanks very much for the comments.

I have an [updated patch][1] that attempts to address these issues for 
further review for inclusion in BORDEAUX-THREADS.

[1]: 
http://detroit.slack.net/~evenson/abcl/bordeaux-threads-abcl-20110318a.diff

> 1) If no other threads are trying to claim the lock, then condition-wait will
> return immediately rather than waiting.

I couldn't reproduce this behavior.  In ABCL, the THREADS:OBJECT-WAIT 
implementation is mainly a simple wrapping of the underlying 
[java.lang.Object.wait()][2] which clearly should wait.

[2]: 
http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#wait%28%29

> 2) If two threads are waiting in condition-wait and two other threads call
> condition-notify, then it is possible that only one thread will return from
> condition-wait because the call to acquire-lock in one of them might return
> nil causing it to wait again.

The DO looping construct has been replaced with a simpler subsequent 
BT:ACQUIRE-LOCK that should solve this bug.

(Continue reading)

Martin Simmons | 21 Mar 12:43 2011

Re: [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD

>>>>> On Fri, 18 Mar 2011 08:50:50 +0100, Mark Evenson said:
> 
> On 3/2/11 8:50 PM, Martin Simmons wrote:
> 
> > I think that the implementation of condition-wait has some major problems:
> 
> Thanks very much for the comments.
> 
> I have an [updated patch][1] that attempts to address these issues for 
> further review for inclusion in BORDEAUX-THREADS.
> 
> [1]: 
> http://detroit.slack.net/~evenson/abcl/bordeaux-threads-abcl-20110318a.diff

That looks good to me.

> > 3) If condition-notify is called by one thread when a waiting thread is just
> > about to enter the threads:synchronized-on form (but before it gets
> > synchronized), then the notify will be lost.  This happens because the
> > underlying threading primitives have no "memory" of calls to notify when
> > nothing it waiting (which is also the expected semantics for POSIX condition
> > variables BTW).
> 
> THREADS:SYNCHRONIZED-ON is now the first form executed by 
> BT:CONDITION-WAIT so the window here is considerably narrowed.

Yes, that fixes it for all correct uses (those that call condition-notify
while holding the lock).

--

-- 
(Continue reading)


Gmane