integration with java's threading

Mark Evenson evenson at
Mon Mar 13 07:18:25 UTC 2017

On 3/7/17 16:25, Devon Miller wrote:
> I saw that Bordeaux threads uses a very thin layer of java threads in their
> abcl implementation file.
> I wanted to use some libraries from java that use threading fairly heavily
> (web apis) and was wondering if there had been good testing with exchanging
> data from the lisp layer to the java layer when threading is heavily used
> in the java layer. For example, passing xml and json s-expr into java for
> processing and sending out through a multi-threaded environment i.e. akka
> actors.

I have used Java threading heavily in production instances of ABCL
without encountering any problems.  As you have noticed by browsing
BORDEAUX-THREADS, there really isn't much Lisp-side code to the JVM
threads used by ABCL, so there isn't much to go wrong.

As for abstractions in handling threading, Lisp-based multi-threaded
servers like HUNCHENTOOT work well so if your application message
patterns follows the HTTP synchronous request/response pattern, it
should be easily to stretch existing code in that direction without
having to worry about signalling semantics.

If you need more complicated multi-thread communication mechanism,
LPARALLEL seems to provide a fine "bounded thread pool on queues"
mechanism that I have used to great success for long lived batch
processes whose lifetime is much greater than a typical HTTP
request/response sequence.

And if you really want to just do the threading in pure "Java the
Language", using the abstractions in
[java.util.concurrent][executor-service] with Lisp-side lambdas closed
over the data for a given worker will allow you to create almost any
multi-threaded service that I can imagine.


In general, I find it much easier to reason about lexical variables in
multiple threads so I would avoid special variables until you develop
and can self- articulate an understanding of the ABCL/JVM memory model.

The only other gotcha in thread contention for memory might be in
reading/writing 64-bit JVM primitive values.  This might have "gone
away" in the 64bit JVMs that are prevalent today, as I haven't tested
this for a while.  If you run into problems, I would use the
[java-atomic][] JVM library to guard such access.


Happy threading,

"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

More information about the armedbear-devel mailing list