gmane.lisp.bordeaux-threads.devel

Upcoming 0.8.3 release

Stelian Ionescu — 2013-03-18T20:41:42

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

style-warning in upcoming SBCL-1.1

James M. Lawrence — 2012-10-01T14:57:50

; 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.
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

test suite problem on CMUCL

Anton Vodonosov — 2012-08-06T01:51:59

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

Bordeaux-threads 0.8.2 ported to MKCL.

Jean-Claude Beaudoin — 2012-08-05T03:25:12

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
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

compare-and-swap

Josh Marchán — 2012-07-20T14:00:01

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-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

condition-variable in clozure cl.

박성민 — 2012-07-11T00:07:17

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-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

Clozure: fix condition-wait

James M. Lawrence — 2012-06-30T19:10:09

If release-lock fails then do not call acquire-lock.
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

Allegro 9.0 SMP fixes

James M. Lawrence — 2012-06-30T18:45:04

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).
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

LispWorks impl of threadp shouldn't checkfor simple-process

Martin Simmons — 2012-06-06T14:49:32

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

Bordeaux-Threads release 0.8.2

Stelian Ionescu — 2012-06-03T10:26:28

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

Upcoming release 0.8.2

Stelian Ionescu — 2012-04-17T15:29:39

I'm planning to make a new release, so if anybody has any request,
please speak up

Deprecating recursive locks

Stelian Ionescu — 2012-04-17T15:21:41

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 ?

[patch] LispWorks 6.x MP updates + EOS

Kamil Shakirov — 2012-04-17T12:08:44

Hello,

The attached patches do not add or fix anything, just clean up the
lispworks implementation a bit. ;-)

1) bordeaux-threads-0.8.1+lw6x.patch

This patch updates lispworks implementation reflecting all recent
changes in LispWorks 6.x MP API.

Some MP calls are still available in 6.x but considered deprecated and
removed from documentation.

1.1) current-thread() changes

It is better to use mp:get-current-process() that was introduced in
LispWorks 5.1 instead of mp:*current-process* that can be bound to
another process.

1.2) threadp() changes

MP provides its own predicates for processes.

1.3) acquire-recursive-lock() and release-recursive-lock() changes

I am getting warnings when compiling bordeaux-threads, so why not
'declaim' these calls 'inline' instead (fixed in the patch)

;;;*** Warning in BORDEAUX-THREADS:ACQUIRE-RECURSIVE-LOCK: Inline
expansion for BORDEAUX-THREADS:ACQUIRE-LOCK not found
;;;*** Warning in BORDEAUX-THREADS:ACQUIRE-RECURSIVE-LOCK: Inline
expansion for BORDEAUX-THREADS:ACQUIRE-LOCK not found
; BORDEAUX-THREADS:ACQUIRE-RECURSIVE-LOCK
;;;*** Warning in BORDEAUX-THREADS:RELEASE-RECURSIVE-LOCK: Inline
expansion for BORDEAUX-THREADS:RELEASE-LOCK not found
;;;*** Warning in BORDEAUX-THREADS:RELEASE-RECURSIVE-LOCK: Inline
expansion for BORDEAUX-THREADS:RELEASE-LOCK not found

1.4) join-thread() changes

LispWorks 6.0 introduces its own mp:process-join() function.


2) bordeaux-threads-0.8.1+eos.patch

This patch replaces FiveAM with Eos. Eos has no dependencies and
backward compatible with FIveAM API.

I couldn't manage to load FiveAM in LW because of arnesi loading
errors. All tests work fine with Eos (tested with recent Clozure CL,
SBCL and LW 6.1).

Thank you for your time. ;-)

CONDITION-WAIT with timeout

Thomas Munro — 2012-04-04T21:33:04

Hi

Are there any plans to support a timeout for
bordeaux-threads:condition-wait?  The implementations I'm
aware of support this threading primitive:

* ABCL could presumably do it since Java Object.wait can take a timeout
* SBCL supports it using sb-thread:condition-wait with keyword :timeout [1]
* anything with POSIX threads underneath could use pthread_cond_timedwait

The main variation seems to be between those implementations that
use an absolute time and those that use a relative time (how long
to wait in milliseconds for example).

Since I think I need this feature I might try to write a patch to
do this for ABCL and SBCL if there is nothing already in
the works (unless there is some technical problem I'm not seeing?)

Thanks
Thomas Munro

[1] http://random-state.net/log/3523852985.html

Dead lock in condition wait.

rayfill — 2012-03-29T23:51:36

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

join-thread in allegro

Kiyoshi Mizumaru — 2012-03-25T15:35:19

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-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

test suite crashes CMUCL

Anton Vodonosov — 2012-03-05T23:57:13

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

test failures

Anton Vodonosov — 2012-02-25T19:23:06

Hello.

In the scope of this project https://github.com/cl-test-grid/cl-test-grid
I and Robert Goldman run tests of CL libraries on various CL implementations.

Bordeaux threads tests fails on some implementations, sometimes due to
buts in the tests I suppose.

You may find reports here
http://common-lisp.net/project/cl-test-grid/

Probably the most convenient report to overview a single library 
status is this one:
http://common-lisp.net/project/cl-test-grid/pivot_lib-lisp_ql.html

Between the test results for the recent version of quicklisp 
and the previous one, bordeaux-threads has only one regression:
sbcl-1.0.54.45-a2bef14-macosx-x64.

Probably it's due to some bug (like race conditions) in the tests,
because the Qicklisp Blog doesn't list bordeaux-threads
between updated projects in the last distro update, and if it's true,
than the results are from the same bordeaux-threads
version. http://blog.quicklisp.org/2012/02/february-dist-update-now-available.html

Best regards,
- Anton

Bordeaux-Threads release 0.8.1

Stelian Ionescu — 2011-08-02T22:49:39

There's a new release of Bordeaux-Threads.

Noteworthy changes since 0.8.0:
      * Update ABCL support, reimplementing locks based on
        java.util.concurrent.locks.ReentrantLock and adding condition
        variables - thanks to Mark Evenson 
      * Remove warning about threads not being supported, when
        applicable

patch for thread-wait

Faré — 2010-12-14T01:22:11

Dear bordeaux-threads developers,

I have a patch that adds bt support for thread-wait and
thread-wait-with-timeout, modelled after the process-wait and
process-wait-with-timeout functions sported by several Lisp APIs.

This API should be considered a legacy compatibility API, as these
operations may have made sense long ago on timesharing monoprocessors,
but are necessarily expensive on multiprocessors. Nevertheless, we had
a use for them at ITA, and I threw together this compatibility
support, until we get our code cleaned up.

Please consider this patch for inclusion, though it has only been
lightly tested.

PS: I also have a patch to add XCVB support to bordeaux-threads,
though you might not be interested.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
As the Chinese say, 1001 words is worth more than a picture.  — John McCarthy
_______________________________________________
Bordeaux-threads-devel mailing list
Bordeaux-threads-devel-F1HGIaG5STRyXAeb93iumQ< at >public.gmane.org
http://common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel

binding output stream in thread for slimeuse

Antony — 2010-12-11T09:47:15

Hi

I am trying to use bordeaux threads.
Trying to figure out how to make output from a thread function appear in 
slime instead of the lisp terminal.
The lisp I am using is
Clozure Common Lisp Version 1.6-r14468M  (WindowsX8664)

I beleive I have the latest bordeaux threads

Following is my test code. I hope the intentions are clear.

What am I doing wrong or missing?

Code follows
Thanks,
-Antony

(asdf:oos 'asdf:load-op :bordeaux-threads)

(format t "~%appearing in slime")

(defun thread-test ()
   (format t "~%appearing in lisp terminal: ~A"
           (bordeaux-threads:thread-name 
(bordeaux-threads:current-thread))))

(let ((bindings
        '((*standard-input* . *standard-input*)
          (*standard-output* . *standard-output*)
          (*query-io* . *query-io*)
          (*trace-output* . *trace-output*))))  ;;is this correct?
   (dolist (name '("foo" "bar"))
         (bordeaux-threads:make-thread #'thread-test
                                       :name name
                                       :initial-bindings bindings)))