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
_______________________________________________ Bordeaux-threads-devel mailing list Bordeaux-threads-devel@... http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
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
_______________________________________________ Bordeaux-threads-devel mailing list Bordeaux-threads-devel@... http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
Hello, The attached patches do not add or fix anything, just clean up the lispworks implementation a bit.(Continue reading)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
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
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)))
(Continue reading)
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
_______________________________________________ Bordeaux-threads-devel mailing list Bordeaux-threads-devel@... http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
I've forgot to send this to the list. ---------- Forwarded message ---------- From: Kiyoshi Mizumaru <kiyoshi.mizumaru@...> Date: Mon, Mar 26, 2012 at 1:02 PM Subject: Re: [Bordeaux-threads-devel] join-thread in allegro To: Stelian Ionescu <sionescu@...> 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@...> On Mon, Mar 26, 2012 at 8:24 AM, Stelian Ionescu <sionescu@...> 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(Continue reading)
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@...>
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
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
_______________________________________________ Bordeaux-threads-devel mailing list Bordeaux-threads-devel@... http://lists.common-lisp.net/cgi-bin/mailman/listinfo/bordeaux-threads-devel
RSS Feed11 | |
|---|---|
18 | |
10 | |
5 | |
2 | |
1 | |
5 | |
2 | |
9 | |
3 | |
1 | |
2 | |
5 | |
2 | |
3 | |
13 | |
9 | |
9 | |
2 | |
2 | |
1 | |
11 | |
1 | |
1 | |
10 | |
3 | |
4 | |
6 | |
5 | |
1 | |
1 | |
5 | |
1 | |
1 | |
1 | |
2 | |
4 | |
1 | |
1 | |
1 | |
3 |
