bordeaux-threads-devel

bordeaux-threads-devel@common-lisp.net

87 discussions

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 06 Aug '12

06 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

bordeaux-threads-devel