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

[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

[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