[armedbear-devel] Better multithreading support (was Re: [Bordeaux-threads-devel] [Updated4] Patch for ABCL against BORDEAUX-THREADS HEAD)

[Chun Tian (binghe)]

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/vendor/portable-threads.lisp
[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%28long%29
> 
> 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/Condition.html#await%28long,%20java.util.concurrent.TimeUnit%29
> 
> 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/package-summary.html
> 
> 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel