gmane.lisp.bordeaux-threads.devel

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

Patch for ABCL againstBORDEAUX-THREADS-0.8.0

Mark Evenson — 2010-12-03T13:37:52

ABCL's multithreading symbols have moved to THREADS package (this was 
deprecated with abcl-0.18 and removed with abcl-0.22).

Implement CONDITION-WAIT and CONDITION-NOTIFY for ABCL.

Use 10ms pause for ABCL's THREAD-YIELD.

Clarifying some behavior in thedocumentation

Vladimir Sedach — 2010-11-30T05:02:05

Hello,

I've encountered two cases that affect behavior of code but aren't
clarified in the documentation:

1. At least one implementation (SBCL) requires that the lock on which
condition-wait is called is to be held by the thread that calls
condition-notify on the corresponding CV. This should be mentioned in
the documentation as a requirement.

2. It is undefined what happens when release-lock is called inside a
with-lock-held on the same lock. SBCL and Clozure appear to handle
this "properly," although I think the documented behavior should be
the same as with regular release-lock ("It is an error to call this
unless the lock has previously been acquired (and not released) by the
same thread," that is, it should be an error to call release-lock
inside a with-lock-held).

Thank you,
Vladimir

Bordeaux-Threads release 0.8.0

Stelian Ionescu — 2010-10-02T13:52:46

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

default-special-bindings docstring in0-8-8-dev

james anderson — 2010-09-04T09:23:56

re:

(defvar *default-special-bindings* nil
   "This variable holds an alist associating special variable symbols
   to forms to evaluate. Special variables named in this list will
   be locally bound in the new thread before it begins executing user  
code.

   This variable may be rebound around calls to MAKE-THREAD to
   add/alter default bindings. The effect of mutating this list is
   undefined, but earlier forms take precedence over later forms for
   the same symbol, so defaults may be overridden by consing to the
   head of the list.")

at least for sbcl and clozure, one needs to append to the list.
does the spec say something else somewhere?


* (progv '(a s a) '(1 2 3) a)

; in: LAMBDA NIL
;     (PROGV '(A S A) '(1 2 3) A)
; --> LET UNWIND-PROTECT FLET BLOCK MULTIPLE-VALUE-BIND MULTIPLE- 
VALUE-CALL
; --> BLOCK SB-C::%WITHIN-CLEANUP RETURN-FROM
; ==>
;   (PROGN
;    (LABELS ((#:UNBIND1 (SB-C::VARS)
;               (DECLARE #)
;               (LET #
;                 #))
;             (#:BIND0 (SB-C::VARS SB-C::VALS)
;               (DECLARE #)
;               (COND # # #)))
;      (#:BIND0 '(A S A) '(1 2 3)))
;    NIL
;    A)
;
; caught WARNING:
;   undefined variable: A
;
; compilation unit finished
;   Undefined variable:
;     A
;   caught 1 WARNING condition

3
*

ECL implementation update

Kamil Shakirov — 2010-08-23T17:49:47

Hi List,

The attached patch adds support for condition variables and recursive locks
supported by ECL implementation. All test cases now pass with ECL 10.7.1.

--
wbr.

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

Is there a multi-implementation way to geta timeout on condition-notify?

Matt Lamari — 2010-08-18T20:51:11

On lispworks (6) there's condition-notify-with-timeout.

On SBCL - not sure - there's a with-timeout that can make a form throw;
but a little birdie told me that it's not supported on all platforms.


Any good ideas?

I've toyed with ideas for emulating it; but they tend to fall down under
scrutiny.

[BUG-FIX] Error: Symbol "CONDITION-SIGNAL"not found at all in the MP package.

Ryan Hope — 2010-08-18T19:11:12

I get this error "Error: Symbol "CONDITION-SIGNAL" not found at all in
the MP package." using bordeaux-threads from git on Lispworks6. Below
is a fix...

diff --git a/src/impl-lispworks.lisp b/src/impl-lispworks.lisp
index 8c88b30..949e7ff 100644
--- a/src/impl-lispworks.lisp
+++ b/src/impl-lispworks.lisp
< at >< at > -78,7 +78,7 < at >< at > Distributed under the MIT license (see LICENSE file)

 #+(or lispworks6)
 (defun condition-notify (condition-variable)
-  (mp:condition-signal condition-variable))
+  (mp:condition-variable-signal condition-variable))

 (defun thread-yield ()
   (mp:process-allow-scheduling))

Docs link dead.

Robin Lee Powell — 2010-07-11T05:16:08

The API documentation link on
http://common-lisp.net/project/bordeaux-threads/ is dead, and I
can't find a replacement.

-Robin

Source repository switch to git

Stelian Ionescu — 2010-05-07T14:51:09

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

license verification for inclusion inde.setf.amqp

james anderson — 2010-02-15T12:44:15

good morning;

i have released a library, de.setf.amqp[1], which incorporates work  
of yours. the combined license is the gnu affero. please see the  
readme[2] for more information. this is to verify the contact  
information for your library's license. yours is the last respective  
contact. in some cases, there was none and i have substituted a  
mailing list as an immediate place-holder, even though, as  
subscription-only lists, it is not well suited to this purpose.  
please advise me, should an alternative contact be available.

[1] : http://github.com/lisp/de.setf.amqp
[2] : http://github.com/lisp/de.setf.amqp/blob/master/README.md