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

[Alessio Stalla]

On Mon, Mar 21, 2011 at 4:04 PM, Mark Evenson <evenson at panix.com> wrote:
> 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.

Is condition-wait's return value significant? If not, it could be a
boolean telling the user the if a timeout is the reason for the
wakeup. object-wait would need to be modified accordingly. However,
this is stepping outside the bordeaux-threads API, your code won't be
portable.

>
> [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

That's the way to do it on the JVM, but note that you need to declare
in advance that you want an atomically-updatable "thing":

(let ((foo 1)) (atomic-incf foo)) ;;won't work
(let ((foo (make-atomic-integer 1))) (atomic-incf foo)) ;;this will

this means you can't mix atomic references with unaware code, unless
we provide atomic versions of LispObject and friends.

Alessio