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

[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