From martin at lispworks.com  Tue Jul  3 13:11:12 2012
From: martin at lispworks.com (Martin Simmons)
Date: Tue, 3 Jul 2012 14:11:12 +0100
Subject: [Bordeaux-threads-devel] Clozure: fix condition-wait
In-Reply-To: <CAAmBhX-vaaBCZHK4=y9Y56tSKeXMmy2XKc8XH3-o3GaTYWyakg@mail.gmail.com>
	(llmjjmll@gmail.com)
References: <CAAmBhX-vaaBCZHK4=y9Y56tSKeXMmy2XKc8XH3-o3GaTYWyakg@mail.gmail.com>
Message-ID: <201207031311.q63DBCoZ001640@higson.cam.lispworks.com>

>>>>> On Sat, 30 Jun 2012 15:10:09 -0400, James M Lawrence said:
> 
> If release-lock fails then do not call acquire-lock.

What can cause release-lock to fail?  Or do you mean that something might do
an async throw on entry to release-lock?  If so, what prevents an async throw
on exit from release-lock in the new version (causing the opposite bug)?

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/



From llmjjmll at gmail.com  Thu Jul  5 22:52:37 2012
From: llmjjmll at gmail.com (James M. Lawrence)
Date: Thu, 5 Jul 2012 18:52:37 -0400
Subject: [Bordeaux-threads-devel] Allegro 9.0 SMP fixes
In-Reply-To: <CAAmBhX_JV2Mh303U4fkw_52iXZALuZ_3aKOB38MENRKE2TAt3A@mail.gmail.com>
References: <CAAmBhX_JV2Mh303U4fkw_52iXZALuZ_3aKOB38MENRKE2TAt3A@mail.gmail.com>
Message-ID: <CAAmBhX-6tbpuwpXL2oQqvd5-35duwM33xQMSpVf85rmcbV-Ung@mail.gmail.com>

Condition variables were added to the Allegro documentation the day
after I sent the last patch, which I assume is sheer coincidence. The
attached patch using condition variables is better. This is for both
Allegro 8.2 and 9.0.

On Sat, Jun 30, 2012 at 2:45 PM, James M. Lawrence <llmjjmll at gmail.com> wrote:
> The first patch is a stress test which will hang without the
> subsequent patch.
>
> This patch covers all Allegro versions. The code was incorrect all
> along, but symptoms only appeared with real SMP.
>
> Thanks to Franz support for recommending the solution.
>
> The stress test may also fail intermittently for unrelated reasons.
> Franz is aware of this problem (which stems from the weak-keys hash in
> impl-allegro.lisp).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Allegro-use-condition-variables.patch
Type: application/octet-stream
Size: 1665 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20120705/994e2be2/attachment.obj>

From llmjjmll at gmail.com  Thu Jul  5 23:16:56 2012
From: llmjjmll at gmail.com (James M. Lawrence)
Date: Thu, 5 Jul 2012 19:16:56 -0400
Subject: [Bordeaux-threads-devel] Clozure: fix condition-wait
In-Reply-To: <201207031311.q63DBCoZ001640@higson.cam.lispworks.com>
References: <CAAmBhX-vaaBCZHK4=y9Y56tSKeXMmy2XKc8XH3-o3GaTYWyakg@mail.gmail.com>
	<201207031311.q63DBCoZ001640@higson.cam.lispworks.com>
Message-ID: <CAAmBhX9OTtxu3O50a6V+8QRt6pbTznF_q8Dfxt2e9WNinMqzfg@mail.gmail.com>

On Tue, Jul 3, 2012 at 9:11 AM, Martin Simmons <martin at lispworks.com> wrote:
>>>>>> On Sat, 30 Jun 2012 15:10:09 -0400, James M Lawrence said:
>>
>> If release-lock fails then do not call acquire-lock.
>
> What can cause release-lock to fail?  Or do you mean that something might do
> an async throw on entry to release-lock?  If so, what prevents an async throw
> on exit from release-lock in the new version (causing the opposite bug)?

release-lock signals an error when the lock is not owned. Without the
patch, when condition-wait fails in this manner it silently acquires
the lock. To complicate matters, CCL lacks non-recursive locks
(consecutive acquire-lock calls do not cause an error), so this local
failure can cause a global problem which is not immediately detected.

If we are talking about interrupts then there are problems in either
case, both before and after the patch. Making condition-wait robust in
the face of interrupts is a different issue, and may not be possible
here. One solution might be the following, although it may have
implications of its own.

(defun condition-wait (condition-variable lock)
  (ccl:without-interrupts
    (release-lock lock)
    (unwind-protect
         (ccl:with-interrupts-enabled
           (ccl:wait-on-semaphore condition-variable))
      (acquire-lock lock))))



From byulparan at gmail.com  Wed Jul 11 00:07:17 2012
From: byulparan at gmail.com (=?EUC-KR?B?udq8urnO?=)
Date: Wed, 11 Jul 2012 09:07:17 +0900
Subject: [Bordeaux-threads-devel] condition-variable in clozure cl.
Message-ID: <CANebJyejaBin27NiJjBA9POOx7eJ9wJDTUnMjCQ3e7seREWc+A@mail.gmail.com>

clozure cl haven't implements condition-variable. so..

(defun bt:make-condition-variable ()
  (ccl:make-semaphore))


but, condition-variable and semaphore are different. right?
It can cause problems, I think.
Perhaps, It's make meaningless loop.

I just wonder why something like this that you have not implemented in
bordeaux-threads


(in-package #:bordeaux-threads)

(defclass condition-variable ()
  ((sem-count :initform 0 :accessor sem-count)
   (semaphore :initform (ccl:make-semaphore) :reader semaphore)))


(defun make-condition-variable ()
  (make-instance 'condition-variable))


(defun condition-wait (condition-variable lock)
  (unwind-protect (progn (incf (sem-count condition-variable))
 (release-lock lock)
 (ccl:wait-on-semaphore (semaphore condition-variable)))
    (acquire-lock lock)))


(defun condition-notify (condition-variable)
  (when (> (sem-count condition-variable) 0)
    (decf (sem-count condition-variable))
    (ccl:signal-semaphore (semaphore condition-variable))))



I don't know about it....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20120711/fc74faec/attachment.html>

From sykopomp at sykosomatic.org  Fri Jul 20 14:00:01 2012
From: sykopomp at sykosomatic.org (Josh =?iso-8859-1?Q?March=E1n?=)
Date: Fri, 20 Jul 2012 10:00:01 -0400
Subject: [Bordeaux-threads-devel] compare-and-swap
Message-ID: <20120720140001.GA1193@Zushakon>

Lu?s Oliveira recently published a blog post
(http://kvardek-du.kerno.org/2012/06/augmenting-bordeaux-threads-with-atomic.html)
iscussing the possibility of extending BT with atomic operations (like
compare-and-swap). He put together a very handy table about implementation
support for this operation, which gives the impression that it might indeed
be a good time to wrap this feature in a portable API.

I'm working on a library that happens to use compare-and-swap, and wrote
the following macro:

(defmacro compare-and-swap (place old-value new-value)
   #+sbcl
   (let ((old-val-var (gensym "OLD-VALUE-")))
     ` (let ((,old-val-var ,old-value))
         (eq ,old-val-var (sb-ext:compare-and-swap ,place ,old-val-var
         ,new-value))))
   #+ccl
   `(ccl::conditional-store ,place ,old-value ,new-value)
   #+lispworks
   `(system:compare-and-swap ,place ,old-value ,new-value)
   #+allegro
   `(excl:atomic-conditional-setf ,place ,new-value ,old-value)
   #-(or allegro lispworks ccl sbcl) `(error "Not supported."))

I've tested this in all the mentioned implementations. I'm considering
putting together a patch to add this macro to BT itself, and I'd like to
know if this would be wanted, if there's any issues with the API itself,
etc.

There are two big issues I see:

1. On CCL, conditional-store is an internal, unexported operation. It's
also pretty narrow in what it can handle, and even breaks in situations
such as typed struct slot access. rme was kind enough to create a ticket
for this on the Clozure CL tracker, so this issue may be resolved in the
(near?) future: http://trac.clozure.com/ccl/ticket/994

2. CAS support across implementations has a lot of 'but's associated with
it. The only thing that seems to be supported across the listed
implementations is svref and struct access. There's also weird behavior on
some implementations (notably SBCL) when it comes to accessing dynamic
variables (where it can only access the global binding, not the local
one). Is this acceptable? Should a patch include compile-time warnings or
errors when we detect (when possible) that CAS is being used on an
unsupported place? Should it be left up to users to use it in the right
case? Should it break for anything other than svref and structslot, which
are the only ones supported across the board?

--
Josh March?n
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20120720/24e34b8a/attachment.sig>

From fahree at gmail.com  Fri Jul 20 20:58:34 2012
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Fri, 20 Jul 2012 16:58:34 -0400
Subject: [Bordeaux-threads-devel] compare-and-swap
In-Reply-To: <20120720140001.GA1193@Zushakon>
References: <20120720140001.GA1193@Zushakon>
Message-ID: <CAN7nBXe++ebdiRc_SD_ps+FpXdGEGUk3O_GVbVhECoa=Ubwp-w@mail.gmail.com>

On Fri, Jul 20, 2012 at 10:00 AM, Josh March?n <sykopomp at sykosomatic.org> wrote:
> 2. CAS support across implementations has a lot of 'but's associated with
> it. The only thing that seems to be supported across the listed
> implementations is svref and struct access. There's also weird behavior on
> some implementations (notably SBCL) when it comes to accessing dynamic
> variables (where it can only access the global binding, not the local
> one). Is this acceptable? Should a patch include compile-time warnings or
> errors when we detect (when possible) that CAS is being used on an
> unsupported place? Should it be left up to users to use it in the right
> case? Should it break for anything other than svref and structslot, which
> are the only ones supported across the board?
>
My API suggestion is to issue
1- an error if you're using the form in a way that is not supported on
the current platform.
2- a warning if you're using the form in a way that is supported on
the current platform but not universally.

The error and warning should use a defined condition, so that they can
be suitably handled.

??? ? Fran?ois-Ren? ?VB Rideau ?Reflection&Cybernethics? http://fare.tunes.org
It is a sorry society where honest people need to carry a gun,
but a sorrier society where they need to carry one but can't.



From pvk at pvk.ca  Sat Jul 21 13:42:30 2012
From: pvk at pvk.ca (Paul Khuong)
Date: Sat, 21 Jul 2012 09:42:30 -0400
Subject: [Bordeaux-threads-devel] compare-and-swap
References: <20120720140001.GA1193@Zushakon>
Message-ID: <pvk-B8A2BC.09422921072012@news.gmane.org>

In article <20120720140001.GA1193 at Zushakon>,
 Josh March?n <sykopomp at sykosomatic.org> wrote:

> There's also weird behavior on
> some implementations (notably SBCL) when it comes to accessing dynamic
> variables (where it can only access the global binding, not the local
> one).

I don't know where you're getting that. SYMBOL-VALUE works with dynamic 
variables and their current dynamic binding, if any.

Paul Khuong




From sykopomp at sykosomatic.org  Sat Jul 21 14:42:16 2012
From: sykopomp at sykosomatic.org (Josh =?iso-8859-1?Q?March=E1n?=)
Date: Sat, 21 Jul 2012 10:42:16 -0400
Subject: [Bordeaux-threads-devel] compare-and-swap
In-Reply-To: <pvk-B8A2BC.09422921072012@news.gmane.org>
References: <20120720140001.GA1193@Zushakon>
	<pvk-B8A2BC.09422921072012@news.gmane.org>
Message-ID: <20120721144216.GB1193@Zushakon>

On Sat, Jul 21, 2012 at 09:42:30AM -0400, Paul Khuong wrote:
>In article <20120720140001.GA1193 at Zushakon>,
> Josh March?n <sykopomp at sykosomatic.org> wrote:
>
>> There's also weird behavior on
>> some implementations (notably SBCL) when it comes to accessing dynamic
>> variables (where it can only access the global binding, not the local
>> one).
>
>I don't know where you're getting that. SYMBOL-VALUE works with dynamic
>variables and their current dynamic binding, if any.

You're right. I hadn't tested it myself. I got that from Luis' post:

> (2012-06-10 update: Nikodemus wrote in to point out that (cas
> (symbol-value '*foo*) ...) on SBCL modifies the special variable's global
> value rather than its dynamic binding. Fixed table accordingly.)

-- 
Josh March?n
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/bordeaux-threads-devel/attachments/20120721/811f064c/attachment.sig>

From sionescu at cddr.org  Sun Jul 29 14:16:42 2012
From: sionescu at cddr.org (Stelian Ionescu)
Date: Sun, 29 Jul 2012 16:16:42 +0200
Subject: [Bordeaux-threads-devel] Allegro 9.0 SMP fixes
In-Reply-To: <CAAmBhX-6tbpuwpXL2oQqvd5-35duwM33xQMSpVf85rmcbV-Ung@mail.gmail.com>
References: <CAAmBhX_JV2Mh303U4fkw_52iXZALuZ_3aKOB38MENRKE2TAt3A@mail.gmail.com>
	<CAAmBhX-6tbpuwpXL2oQqvd5-35duwM33xQMSpVf85rmcbV-Ung@mail.gmail.com>
Message-ID: <1343571402.21922.0.camel@cathai>

On Thu, 2012-07-05 at 18:52 -0400, James M. Lawrence wrote:
> Condition variables were added to the Allegro documentation the day
> after I sent the last patch, which I assume is sheer coincidence. The
> attached patch using condition variables is better. This is for both
> Allegro 8.2 and 9.0.

Thanks, patch committed

-- 
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/20120729/e369814e/attachment.sig>

From sionescu at cddr.org  Sun Jul 29 14:17:06 2012
From: sionescu at cddr.org (Stelian Ionescu)
Date: Sun, 29 Jul 2012 16:17:06 +0200
Subject: [Bordeaux-threads-devel] Clozure: fix condition-wait
In-Reply-To: <CAAmBhX-vaaBCZHK4=y9Y56tSKeXMmy2XKc8XH3-o3GaTYWyakg@mail.gmail.com>
References: <CAAmBhX-vaaBCZHK4=y9Y56tSKeXMmy2XKc8XH3-o3GaTYWyakg@mail.gmail.com>
Message-ID: <1343571426.21922.1.camel@cathai>

On Sat, 2012-06-30 at 15:10 -0400, James M. Lawrence wrote:
> If release-lock fails then do not call acquire-lock.

Thanks, patch committed

-- 
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/20120729/0843325e/attachment.sig>