From avodonosov at yandex.ru  Mon Mar  5 23:57:13 2012
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Tue, 06 Mar 2012 03:57:13 +0400
Subject: [Bordeaux-threads-devel] test suite crashes CMUCL
Message-ID: <957741330991833@web52.yandex.ru>

BTW, another tests issue I forgot to report:

On CMUCL bordeaux-threads test suite traps into some active
deadlock, produces 8 MB of '.' symbols in log, constantly runs GC
and finally dies when heap is exhausted.

Best regards,
- Anton



From avodonosov at yandex.ru  Mon Mar  5 23:58:36 2012
From: avodonosov at yandex.ru (Anton Vodonosov)
Date: Tue, 06 Mar 2012 03:58:36 +0400
Subject: [Bordeaux-threads-devel] test suite crashes CMUCL
In-Reply-To: <957741330991833@web52.yandex.ru>
References: <957741330991833@web52.yandex.ru>
Message-ID: <246231330991917@web139.yandex.ru>

The platform is cmu-20c_release-20c__20c_unicode_-linux-x86.

06.03.2012, 03:57, "Anton Vodonosov" <avodonosov at yandex.ru>:
> BTW, another tests issue I forgot to report:
>
> On CMUCL bordeaux-threads test suite traps into some active
> deadlock, produces 8 MB of '.' symbols in log, constantly runs GC
> and finally dies when heap is exhausted.
>
> Best regards,
> - Anton
>
> _______________________________________________
> 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 kiyoshi.mizumaru at gmail.com  Sun Mar 25 15:35:19 2012
From: kiyoshi.mizumaru at gmail.com (Kiyoshi Mizumaru)
Date: Mon, 26 Mar 2012 00:35:19 +0900
Subject: [Bordeaux-threads-devel] join-thread in allegro
Message-ID: <CAPrZCAsw+0yQo0XR2-5+hk1W4_19J5nb7H6zDfc469Zqp=X2sQ@mail.gmail.com>

Hi,

Even though the api documentation doesn't mention it, I've found that
join-thread is expected to have a value of the thread's function in some
lisp implementations.

(asdf:test-system :sqlite) always fails in concurrent access test since
it checks return values of join-thread and join-thread's value is nil in
current implementation for Allegro CL.  The followings are changes I've made
to correct this problem, so please have a look at it.

https://bitbucket.org/kmizumar/bordeaux-threads/changeset/5de529f36b92
https://bitbucket.org/kmizumar/bordeaux-threads/changeset/549bbcdcf794

Thanks in advance and sorry for my poor English, I'm still learning it.

Kiyoshi
--
Kiyoshi Mizumaru <kiyoshi.mizumaru at gmail.com>



From sionescu at cddr.org  Sun Mar 25 23:24:33 2012
From: sionescu at cddr.org (Stelian Ionescu)
Date: Mon, 26 Mar 2012 01:24:33 +0200
Subject: [Bordeaux-threads-devel] join-thread in allegro
In-Reply-To: <CAPrZCAsw+0yQo0XR2-5+hk1W4_19J5nb7H6zDfc469Zqp=X2sQ@mail.gmail.com>
References: <CAPrZCAsw+0yQo0XR2-5+hk1W4_19J5nb7H6zDfc469Zqp=X2sQ@mail.gmail.com>
Message-ID: <1332717873.19990.1.camel@cathai>

On Mon, 2012-03-26 at 00:35 +0900, Kiyoshi Mizumaru wrote:
> Hi,
> 
> Even though the api documentation doesn't mention it, I've found that
> join-thread is expected to have a value of the thread's function in some
> lisp implementations.
> 
> (asdf:test-system :sqlite) always fails in concurrent access test since
> it checks return values of join-thread and join-thread's value is nil in
> current implementation for Allegro CL.  The followings are changes I've made
> to correct this problem, so please have a look at it.
> 
> https://bitbucket.org/kmizumar/bordeaux-threads/changeset/5de529f36b92
> https://bitbucket.org/kmizumar/bordeaux-threads/changeset/549bbcdcf794
> 
> Thanks in advance and sorry for my poor English, I'm still learning it.

I committed a different implementation that uses a hash-table to store
the return values, which doesn't require us to create a new process
class. Please test and is some test fails, send the output

-- 
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/20120326/2a4c421c/attachment.sig>

From kiyoshi.mizumaru at gmail.com  Mon Mar 26 05:05:40 2012
From: kiyoshi.mizumaru at gmail.com (Kiyoshi Mizumaru)
Date: Mon, 26 Mar 2012 14:05:40 +0900
Subject: [Bordeaux-threads-devel] Fwd:  join-thread in allegro
In-Reply-To: <CAPrZCAsFAjC1=_q7+Pu0E_fGZstP6R2mtwhg7fBnEjJbW2jf=w@mail.gmail.com>
References: <CAPrZCAsw+0yQo0XR2-5+hk1W4_19J5nb7H6zDfc469Zqp=X2sQ@mail.gmail.com>
	<1332717873.19990.1.camel@cathai>
	<CAPrZCAsFAjC1=_q7+Pu0E_fGZstP6R2mtwhg7fBnEjJbW2jf=w@mail.gmail.com>
Message-ID: <CAPrZCAvGFZg0MrkDcR5h2eLmUAMLQ8CCSOCoBLjVSqaK65SSyw@mail.gmail.com>

I've forgot to send this to the list.


---------- Forwarded message ----------
From: Kiyoshi Mizumaru <kiyoshi.mizumaru at gmail.com>
Date: Mon, Mar 26, 2012 at 1:02 PM
Subject: Re: [Bordeaux-threads-devel] join-thread in allegro
To: Stelian Ionescu <sionescu at cddr.org>


I think it's good idea to solve this without defining a new process class.
But in b03b582, make-lock, with-lock-held and current-thread are used
prior to be
defined, and lead to compile error.

Moving the "Thread creation" section solved this and works as expected:
https://bitbucket.org/kmizumar/bordeaux-threads/changeset/02cc8c9b4ce7

Kiyoshi
--
Kiyoshi Mizumaru <kiyoshi.mizumaru at gmail.com>


On Mon, Mar 26, 2012 at 8:24 AM, Stelian Ionescu <sionescu at cddr.org> wrote:
> On Mon, 2012-03-26 at 00:35 +0900, Kiyoshi Mizumaru wrote:
>> Hi,
>>
>> Even though the api documentation doesn't mention it, I've found that
>> join-thread is expected to have a value of the thread's function in some
>> lisp implementations.
>>
>> (asdf:test-system :sqlite) always fails in concurrent access test since
>> it checks return values of join-thread and join-thread's value is nil in
>> current implementation for Allegro CL. ?The followings are changes I've made
>> to correct this problem, so please have a look at it.
>>
>> https://bitbucket.org/kmizumar/bordeaux-threads/changeset/5de529f36b92
>> https://bitbucket.org/kmizumar/bordeaux-threads/changeset/549bbcdcf794
>>
>> Thanks in advance and sorry for my poor English, I'm still learning it.
>
> I committed a different implementation that uses a hash-table to store
> the return values, which doesn't require us to create a new process
> class. Please test and is some test fails, send the output
>
> --
> Stelian Ionescu a.k.a. fe[nl]ix
> Quidquid latine dictum sit, altum videtur.
> http://common-lisp.net/project/iolib
>
>
> _______________________________________________
> 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 sionescu at cddr.org  Mon Mar 26 14:38:58 2012
From: sionescu at cddr.org (Stelian Ionescu)
Date: Mon, 26 Mar 2012 16:38:58 +0200
Subject: [Bordeaux-threads-devel] join-thread in allegro
In-Reply-To: <CAPrZCAsFAjC1=_q7+Pu0E_fGZstP6R2mtwhg7fBnEjJbW2jf=w@mail.gmail.com>
References: <CAPrZCAsw+0yQo0XR2-5+hk1W4_19J5nb7H6zDfc469Zqp=X2sQ@mail.gmail.com>
	<1332717873.19990.1.camel@cathai>
	<CAPrZCAsFAjC1=_q7+Pu0E_fGZstP6R2mtwhg7fBnEjJbW2jf=w@mail.gmail.com>
Message-ID: <1332772738.3292.2.camel@cathai>

On Mon, 2012-03-26 at 13:02 +0900, Kiyoshi Mizumaru wrote:
> I think it's good idea to solve this without defining a new process class.
> But in b03b582, make-lock, with-lock-held and current-thread are used
> prior to be
> defined, and lead to compile error.
> 
> Moving the "Thread creation" section solved this and works as expected:
> https://bitbucket.org/kmizumar/bordeaux-threads/changeset/02cc8c9b4ce7

Ok, I committed the move

-- 
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/20120326/ce745624/attachment.sig>

From kiyoshi.mizumaru at gmail.com  Mon Mar 26 17:03:47 2012
From: kiyoshi.mizumaru at gmail.com (Kiyoshi Mizumaru)
Date: Tue, 27 Mar 2012 02:03:47 +0900
Subject: [Bordeaux-threads-devel] join-thread in allegro
In-Reply-To: <1332772738.3292.2.camel@cathai>
References: <CAPrZCAsw+0yQo0XR2-5+hk1W4_19J5nb7H6zDfc469Zqp=X2sQ@mail.gmail.com>
	<1332717873.19990.1.camel@cathai>
	<CAPrZCAsFAjC1=_q7+Pu0E_fGZstP6R2mtwhg7fBnEjJbW2jf=w@mail.gmail.com>
	<1332772738.3292.2.camel@cathai>
Message-ID: <CAPrZCAusvUqb-UjLFrnV9XO4UPtwNJ7Q-f_wq8U8sO7KUkZEdA@mail.gmail.com>

I'm afraid that I should have mentioned it in previous mail that
incorrect arguments are passed to make-lock function in b03b582.

(defvar *thread-join-lock* (make-lock :name "Bordeaux threads join lock"))

The line should be

(defvar *thread-join-lock* (make-lock "Bordeaux threads join lock*))
--
Kiyoshi Mizumaru <kiyoshi.mizumaru at gmail.com>


On Mon, Mar 26, 2012 at 11:38 PM, Stelian Ionescu <sionescu at cddr.org> wrote:
> On Mon, 2012-03-26 at 13:02 +0900, Kiyoshi Mizumaru wrote:
>> I think it's good idea to solve this without defining a new process class.
>> But in b03b582, make-lock, with-lock-held and current-thread are used
>> prior to be
>> defined, and lead to compile error.
>>
>> Moving the "Thread creation" section solved this and works as expected:
>> https://bitbucket.org/kmizumar/bordeaux-threads/changeset/02cc8c9b4ce7
>
> Ok, I committed the move
>
> --
> Stelian Ionescu a.k.a. fe[nl]ix
> Quidquid latine dictum sit, altum videtur.
> http://common-lisp.net/project/iolib
>
>
> _______________________________________________
> 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 sionescu at cddr.org  Mon Mar 26 18:53:17 2012
From: sionescu at cddr.org (Stelian Ionescu)
Date: Mon, 26 Mar 2012 20:53:17 +0200
Subject: [Bordeaux-threads-devel] join-thread in allegro
In-Reply-To: <CAPrZCAusvUqb-UjLFrnV9XO4UPtwNJ7Q-f_wq8U8sO7KUkZEdA@mail.gmail.com>
References: <CAPrZCAsw+0yQo0XR2-5+hk1W4_19J5nb7H6zDfc469Zqp=X2sQ@mail.gmail.com>
	<1332717873.19990.1.camel@cathai>
	<CAPrZCAsFAjC1=_q7+Pu0E_fGZstP6R2mtwhg7fBnEjJbW2jf=w@mail.gmail.com>
	<1332772738.3292.2.camel@cathai>
	<CAPrZCAusvUqb-UjLFrnV9XO4UPtwNJ7Q-f_wq8U8sO7KUkZEdA@mail.gmail.com>
Message-ID: <1332787997.3292.3.camel@cathai>

On Tue, 2012-03-27 at 02:03 +0900, Kiyoshi Mizumaru wrote:
> I'm afraid that I should have mentioned it in previous mail that
> incorrect arguments are passed to make-lock function in b03b582.
> 
> (defvar *thread-join-lock* (make-lock :name "Bordeaux threads join lock"))
> 
> The line should be
> 
> (defvar *thread-join-lock* (make-lock "Bordeaux threads join lock*))

Ok, fixed

-- 
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/20120326/f42fae91/attachment.sig>

From rayfill at gmail.com  Thu Mar 29 23:51:36 2012
From: rayfill at gmail.com (rayfill)
Date: Fri, 30 Mar 2012 08:51:36 +0900
Subject: [Bordeaux-threads-devel] Dead lock in condition wait.
Message-ID: <CALOceq_ccA9118qZPpSQ763yaOnFecQLkzS1eEj_cZ271K1xiw@mail.gmail.com>

Hi.

I use condition-wait in many acquire recursive-lock. Other thread try
to acquire recusirve-lock's lock at dead locked.

Below code reproduce a problem on Clozure CL.
---
(defvar *condition-variable* (bt:make-condition-variable))
(defvar *recursive-lock* (bt:make-recursive-lock))

(defun worker-job (out)
  (bt:with-recursive-lock-held (*recursive-lock*)
    (bt:with-recursive-lock-held (*recursive-lock*)
      (format out "before condition wait~%")
      (force-output out)
      (bt:condition-wait *condition-variable* *recursive-lock*)
      (format out "after condition wait~%")
      (force-output out))))

(defun condition-use-in-recursive-lock ()
  (let* ((out *standard-output*)
	 (worker (bt:make-thread (lambda () (worker-job out)))))
    (sleep 1)
    (format out "before condition notify~%")
    (force-output out)
    (bt:with-recursive-lock-held (*recursive-lock*) ; Dead lock point.
      (bt:condition-notify *condition-variable*)
      (format out "after condition notify~%")
      (force-output out))
    (bt:join-thread worker)))

(condition-use-in-recurive-lock)
---

conditon-wait is lock release and wait semaphore.
Lock object acquirable many times. but conditon-wait is release lock at once.

I make a patch at here.
https://github.com/rayfill/bordeaux-threads/commit/192124d18a2b2858e6e8aa2cc0409065992d097a

Poor english sorry...


-- 
?rayfill at gmail.com
 Jiro OKAZAKI



From pvk at pvk.ca  Fri Mar 30 17:32:38 2012
From: pvk at pvk.ca (Paul Khuong)
Date: Fri, 30 Mar 2012 13:32:38 -0400
Subject: [Bordeaux-threads-devel] Dead lock in condition wait.
References: <CALOceq_ccA9118qZPpSQ763yaOnFecQLkzS1eEj_cZ271K1xiw@mail.gmail.com>
Message-ID: <pvk-AAECB1.13323830032012@news.gmane.org>

In article 
<CALOceq_ccA9118qZPpSQ763yaOnFecQLkzS1eEj_cZ271K1xiw at mail.gmail.com>,
 rayfill <rayfill at gmail.com> wrote:

> I use condition-wait in many acquire recursive-lock. Other thread try
> to acquire recusirve-lock's lock at dead locked.

Don't.

"Never use a recursive mutex with condition variables because the 
implicit unlock performed by pthread_cond_wait() or 
pthread_cond_timedwait() will not actually release the mutex if it had 
been locked multiple times." 
(see 
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#t
ag_22_02_09_08)

Partially releasing the recursive mutex on condition-wait will almost 
always result in a deadlock. However, fully releasing it may very well 
break invariants in sections of code that acquired the mutex, earlier in 
the call stack.

Paul Khuong