James M. Lawrence | 12 Jun 06:29 2013
Picon

Loading issue in ECL with bordeaux-threads-0.8.3

FYI there is a bug in ECL affecting bordeaux-threads-0.8.3.

    (ql:quickload :bordeaux-threads)
    (bt:make-thread (lambda ()))

There is no problem when bordeaux-threads is compiled for the first
time, however thereafter loading from fasls will result in

    Condition of type: BORDEAUX-MP-CONDITION
    There is no support for this method on this implementation.

The relevant ECL bug is http://sourceforge.net/p/ecls/bugs/261/

This does not affect bordeaux-threads-0.8.2.

Stelian Ionescu | 18 Mar 21:41 2013

Upcoming 0.8.3 release

I'd like to make a new release by this weekend, so please run the test
suite on all available implementations.

--

-- 
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@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
James M. Lawrence | 1 Oct 16:57 2012
Picon

style-warning in upcoming SBCL-1.1

; caught STYLE-WARNING:
;   SB-THREAD:GET-MUTEX has been deprecated as of SBCL 1.0.37.33. Use
;   SB-THREAD:GRAB-MUTEX instead.

The attached patch requires 1.0.38, which appears to have been
released April 2010.

Support for 2.5+ year old compilers may or may not be desirable when
weighed against a style-warning. I don't have a strong opinion.
Attachment (0001-SBCL-use-sb-thread-grab-mutex.patch): application/octet-stream, 1146 bytes
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
Anton Vodonosov | 6 Aug 03:51 2012
Picon

test suite problem on CMUCL

Hello.

When running bordeaux-threads on CMUCL, the test suite 
prints 8 megabytes of dots in output and then crashes
CMUCL with heap exhausted.

Best regards,
- Anton
Jean-Claude Beaudoin | 5 Aug 05:25 2012
Picon

Bordeaux-threads 0.8.2 ported to MKCL.

Hello Bordeaux-threads developers,

Here is attached my port of bordeaux-threads 0.8.2 to MKCL.
The first file is a patch, done with git format-patch against your
git repository on common-lisp.net, that modifies bordeaux-threads.asd.
The second file is to be dropped as is in your "src" directory.

I hope you will find this adequate for your purpose.

Regards,

Jean-Claude Beaudoin

Attachment (0001-Added-support-for-MKCL.patch): application/octet-stream, 1649 bytes
Attachment (impl-mkcl.lisp): application/octet-stream, 2974 bytes
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
Josh Marchán | 20 Jul 16:00 2012

compare-and-swap

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
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
박성민 | 11 Jul 02:07 2012
Picon

condition-variable in clozure cl.


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


_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
James M. Lawrence | 30 Jun 21:10 2012
Picon

Clozure: fix condition-wait

If release-lock fails then do not call acquire-lock.
Attachment (0001-Clozure-fix-condition-wait.patch): application/octet-stream, 1244 bytes
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
James M. Lawrence | 30 Jun 20:45 2012
Picon

Allegro 9.0 SMP fixes

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).
Attachment (0001-add-stress-test.patch): application/octet-stream, 2508 bytes
Attachment (0002-Allegro-fix-invalid-use-of-gates.patch): application/octet-stream, 1385 bytes
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
Martin Simmons | 6 Jun 16:49 2012

LispWorks impl of threadp shouldn't check for simple-process

Please remove the clause for simple-process-p from bordeaux-threads:threadp in
LispWorks.  The main reasons are that the simple process concept hasn't been
supported on most platforms for years and was never a thread (with its own
stack etc).  Another reason is that the symbol mp:simple-process-p still
exists, so the conditionalization doesn't work as expected.

--- src/impl-lispworks.lisp~	2012-06-01 20:17:41.000000000 +0100
+++ src/impl-lispworks.lisp	2012-06-06 15:42:32.642191550 +0100
 <at>  <at>  -30,10 +30,7  <at>  <at> 
   (mp:get-current-process))

 (defun threadp (object)
-  (or (mp:process-p object)
-      ;; removed in LispWorks 6.1
-      #+#.(cl:if (cl:find-symbol (cl:string '#:simple-process-p) :mp) '(and) '(or))
-      (mp:simple-process-p object)))
+  (mp:process-p object))

 (defun thread-name (thread)
   (mp:process-name thread))

--

-- 
Martin Simmons
LispWorks Ltd
http://www.lispworks.com/
Stelian Ionescu | 3 Jun 12:26 2012

Bordeaux-Threads release 0.8.2

There's a new release of Bordeaux-Threads.

Noteworthy changes since 0.8.1:
      * Allegro: JOIN-THREAD now returns the thread function's return
        value instead of just NIL
      * Lispworks: on 6.1+ implement THREAD-JOIN using the native
        primitive mp:process-join

--

-- 
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@...
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

Gmane