- bordeaux-threads-devel - mailman3.common-lisp.net

Testing APIv2
by Stelian Ionescu 09 Jan '22

09 Jan '22

Hi, I'm preparing the release of APIv2 and I'd like everyone to test the new code, especially on implementations that aren't tested in the CI environment: Allegro, Clasp, Genera, MKCL, Lispworks. Here's how to run the tests: (asdf:load-system :bordeaux-threads/test) (5am:run! :bordeaux-threads-2) The documentation for APIv2 is available at https://sionescu.github.io/bordeaux-threads/, and if you encounter test failures or spot mistakes in the docuementation, please file a bug at https://github.com/sionescu/bordeaux-threads/issues/. In the meanwhile I'm working on documenting the differences between APIv1 and APIv2, and perhaps blog about it. -- Stelian Ionescu

1 0

[Bordeaux-threads-devel] CONDITION-WAIT with timeout
by Thomas Munro 14 Sep '13

14 Sep '13

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

3 6

Loading issue in ECL with bordeaux-threads-0.8.3
by James M. Lawrence 12 Jun '13

12 Jun '13

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.

1 0

[Bordeaux-threads-devel] Upcoming 0.8.3 release
by Stelian Ionescu 23 Mar '13

23 Mar '13

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

3 6

[Bordeaux-threads-devel] test suite problem on CMUCL
by Anton Vodonosov 13 Mar '13

13 Mar '13

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

2 2

[Bordeaux-threads-devel] style-warning in upcoming SBCL-1.1
by James M. Lawrence 13 Mar '13

13 Mar '13

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

2 1

[Bordeaux-threads-devel] Bordeaux-threads 0.8.2 ported to MKCL.
by Jean-Claude Beaudoin 05 Aug '12

05 Aug '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

2 3

[Bordeaux-threads-devel] Clozure: fix condition-wait
by James M. Lawrence 29 Jul '12

29 Jul '12

If release-lock fails then do not call acquire-lock.

3 3

[Bordeaux-threads-devel] Allegro 9.0 SMP fixes
by James M. Lawrence 29 Jul '12

29 Jul '12

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

2 2

[Bordeaux-threads-devel] compare-and-swap
by Josh Marchán 21 Jul '12

21 Jul '12

Luís Oliveira recently published a blog post (http://kvardek-du.kerno.org/2012/06/augmenting-bordeaux-threads-with-atomic…) 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

3 3

[Bordeaux-threads-devel] condition-variable in clozure cl.
by 박성민 11 Jul '12

11 Jul '12

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

1 0

[Bordeaux-threads-devel] LispWorks impl of threadp shouldn't check for simple-process
by Martin Simmons 15 Jun '12

15 Jun '12

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 @@ -30,10 +30,7 @@ (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/

2 1

[Bordeaux-threads-devel] Bordeaux-Threads release 0.8.2
by Stelian Ionescu 03 Jun '12

03 Jun '12

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

1 0

Re: [Bordeaux-threads-devel] Deprecating recursive locks
by Anton Vodonosov 10 May '12

10 May '12

18.04.2012, 01:48, "Anton Vodonosov" <avodonosov(a)yandex.ru>: > If the public API is changed in a not-backward-compatible way, I would > suggest to release new ASDF system (bordeaux-threads2), and > leave the old version available in quicklisp forever. > > People who are ready to use new version, just add bordeaux-thread2 > into their ASDF dependency. Others are able to use old version. > > This is a good practice. And it costs nothing. > > Some links on this subject: > http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-l… > http://semver.org/ How to handle backward compatibility of bordeaux-threads if the API is changed is up to the maintainer. Still, I think the approach I suggest may be a good solution for lisp libraries evolution, and I would like to present some arguments to support this approach. 18.04.2012, 08:15, "Attila Lendvai" <attila.lendvai(a)gmail.com>: > IMHO it's not a good practice and it does cost complexity/noise. > > you lose the clarity around the digital representation(s) of the > identity of the library. there's only one b-t library, and the fact > that it has changed in a way that made it incompatible with something > else does not change its identity. No, I only suggest to create separate ASDF system and package for new version of the API. It is not uncommon for lisp project to have several ASDF systems and packages. Should these packages be delivered in the same tarball? They may, but non necessary. (depending what is more convenient for the maintainers). As for the library identity, it can remain the same. What is meant by the library identity and how it is used? Project home page will remain the same, for example, mailing list is the same. I.e. it still remains the same project. If we had two bordeaux-threads versions, one with recursive locks, and one without, why not allow suers to name exactly what API their programs need. 22.04.2012, 18:41, "Stelian Ionescu" <sionescu(a)cddr.org>: > On Wed, 2012-04-18 at 01:48 +0400, Anton Vodonosov wrote: >> Some links on this subject: >> http://lispcaveats.tumblr.com/post/13259176455/ffi-linking-against-shared-l… > That post contains a good analysis of the problem, but then gives the > worst possible advice to solve it Why? At least, this statement is to strong - one can easily create 10 advices worse than the post gives :) If speak seriously, in my opinion referring major version, i.e. specific API, is a good advice. >> http://semver.org/ > Point 5 says "Major version zero (0.y.z) is for initial development. > Anything may change at any time. The public API should not be considered > stable". So no problem there I do not mean we have problem because we contradict some text. I mean that if we have practical problem that N systems will stop to compile after the b-t API changes, leaving the old "frozen" version of API available for these libraries may be a good practical solution for this problem. And the approach of distinguishing changes which modify public API from ones which do not modify the public API is not new. Thus the links, and more examples may be found. IMHO this approach frees the library API to evolve easily, without requiring efforts from the library maintainers, and at the same time not breaking any other systems. Best regards, - Anton

1 0

Re: [Bordeaux-threads-devel] Deprecating recursive locks
by Leslie P. Polzer 03 May '12

03 May '12

Stelian Ionescu wrote: > 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 ? I think it's a bad idea. For me rapid prototyping is an important part of Lisp, and recursive locks support this approach. What Butenhof basically holds against them is that you're not looking at your threading code closely enough. But in the beginning stages of a project I actually might not want to do that. Doing away with them would be premature optimization. Add a note of caution to the docstring if you're that concerned, but don't remove them. Leslie -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

2 1

[Bordeaux-threads-devel] Deprecating recursive locks
by Stelian Ionescu 03 May '12

03 May '12

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 ? -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

7 15

[Bordeaux-threads-devel] [patch] LispWorks 6.x MP updates + EOS
by Kamil Shakirov 21 Apr '12

21 Apr '12

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. ;-) -- --ska

3 4

[Bordeaux-threads-devel] Upcoming release 0.8.2
by Stelian Ionescu 17 Apr '12

17 Apr '12

I'm planning to make a new release, so if anybody has any request, please speak up -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

1 0

[Bordeaux-threads-devel] Dead lock in condition wait.
by rayfill 30 Mar '12

30 Mar '12

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/192124d18a2b2858e6e8aa2c… Poor english sorry... -- rayfill(a)gmail.com Jiro OKAZAKI

2 1

Re: [Bordeaux-threads-devel] join-thread in allegro
by Stelian Ionescu 26 Mar '12

26 Mar '12

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

2 2

[Bordeaux-threads-devel] Fwd: join-thread in allegro
by Kiyoshi Mizumaru 26 Mar '12

26 Mar '12

I've forgot to send this to the list. ---------- Forwarded message ---------- From: Kiyoshi Mizumaru <kiyoshi.mizumaru(a)gmail.com> Date: Mon, Mar 26, 2012 at 1:02 PM Subject: Re: [Bordeaux-threads-devel] join-thread in allegro To: Stelian Ionescu <sionescu(a)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(a)gmail.com> On Mon, Mar 26, 2012 at 8:24 AM, Stelian Ionescu <sionescu(a)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(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel >

1 0

[Bordeaux-threads-devel] join-thread in allegro
by Kiyoshi Mizumaru 25 Mar '12

25 Mar '12

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(a)gmail.com>

2 1

[Bordeaux-threads-devel] test suite crashes CMUCL
by Anton Vodonosov 05 Mar '12

05 Mar '12

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

1 1

[Bordeaux-threads-devel] test failures
by Anton Vodonosov 29 Feb '12

29 Feb '12

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

2 4

[Bordeaux-threads-devel] Bordeaux-Threads release 0.8.1
by Stelian Ionescu 02 Aug '11

02 Aug '11

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 -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib

1 0