Hi, Mark Thanks you very much, now I know how to write CONDITION-VARIABLE-WAIT-WITH-TIMEOUT. Actually I'm working on support of ABCL for PortableThreads [1], based on your work posted these days. Compare to Bordeaux-threads, PortableThreads is much more professional, it did many non-trivial threading API using each platform's exist features as basis. Bordeaux-threads is famous partly because it's ASDF-friendly from the very beginning, but PortableThreads has a single lisp file, which means it's very easy to directly be part of any threading-aware lisp packages, that's just what I did in my package. I've already done most of the porting work, at least the relatively easy part. Do a diff between official version [1] and my version [2] of that single file, you'll find how ABCL support of this package was written. I also have sent an early version to GBBopen's author (Dr. Corkill). PortableThreads also have four atomic operations: ATOMIC-INCF, ATOMIC-DECF, ATOMIC-PUSH and ATOMIC-POP, they do atomic operations on Lisp list and integers. When a platform doesn't have any atomic operator, PortableThread use a general way to support these atomic APIs: define a global lock, and wrap all atomic operations into that single global lock. This is not a efficient way, but do works. I hope once GBBopen official adopts and complete this port, they can do a full unit test on it, to help finding out most of the potential issues in ABCL's current threading support. P. S. For multi-threading APIs among all modern CL platforms, I think LispWorks defines the most beautiful and feature-rich SMP/multi-threading API [3]. However, that's too complex, hard to copy. In practical, PortableThreads API is just enough, I think. Regards, Chun Tian (binghe) [1] http://gbbopen.org/svn/GBBopen/trunk/source/tools/portable-threads.lisp [2] https://cl-net-snmp.svn.sourceforge.net/svnroot/cl-net-snmp/snmp/branches/6/... [3] http://www.lispworks.com/documentation/lw60/LW/html/lw-228.htm#pgfId-885976 在 2011-3-21，23:04， Mark Evenson 写道：
On 3/21/11 15:21 , Chun Tian (binghe) wrote:
Hi, Mark
I'm interesting in your work.
First, I'd like to know, how to do a "condition variable wait with timeout" with your exist work,
It should be pretty easy, as THREADS:OBJECT-WAIT has an optional parameter for TIMEOUT (see [the Java API for the semantics associated with this value][1])
[1]: http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#wait%28lo...
So, one could naively extend my BORDEAUX-THREADS implementation as follows:
(defun condition-wait (condition lock &optional timeout) (threads:synchronized-on condition (release-lock lock) (if timeout (threads:object-wait condition timeout) (threads:object-wait condition)) (acquire-lock lock))
But then a wait on the condition variable which exceeded the timeout would be the same as a thread which was notified, which probably isn't what we want.
If you don't need to follow the B-T API, then I might go for an encapsulation [of the actual Condition class][2] which returns a boolean indicating whether the wait has returned because the timeout has expired.
[2]: http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/Cond...
I'm not sure of your comfort with ABCL's Java FFI, but I would be happy to mentor you through an implementation that suits your needs, subject to possible time delays on my part due to other tasks.
Second, do you think it's possible to make ABCL supporting some atomic operations, something like ATOMIC-INCF or ATOMIC-PUSH, this can be very useful to implement some lockless algorithms.
Here, I would use the [atomic lock-free implementation in the JVM][3], which could give us such things quite cheaply.
[3]: http://download.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/pac...
Do you have a Lisp-side API to recommend?
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
_______________________________________________ armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel