David,

I'm taking a look at fixing up JNIAST to run with threaded AST.
SUN/211 says the following:

    Attempting to use astExport, astImport, astExempt astAnnul or astDelete
    on a pointer that was created in a different thread will lead
    to unpredictable behaviour.

If true, this seems to place quite serious restrictions on the ways
you can use AST objects in a multithreaded context.
The main problem is having to create and annul objects in the same
thread, which means you have to keep quite close tabs on what happens
to an object after you've created it, to make sure that the same thread
gets it back at annulment time.  As JNIAST is currently written, 
astAnnul is called in the corresponding Java object's finalizer, 
which is invoked by the garbage collector in a dedicated finalization 
thread; this will almost certainly not be the same thread in which 
the object was constructed.

The above text goes on to say:

    In general if an Object created in one thread needs to be accessed
    in a second thread, the second thread should create a clone of the
    pointer using astClone, and then use the cloned pointer rather than
    the original pointer.

but obviously cloning an object just to annul it isn't going to help much.
(In any case either this statement is misleading or I've misunderstood:
surely the mechanism for accessing an object created in a different 
thread is astUnlock/astLock not astClone, isn't it?)

The suggestion to use an astBegin/astEnd block in the thread start
function doesn't solve the problem either, since threads may in general
be long-lived.

I'm hoping that the above warning is not quite literally true.
For instance, would it be OK to construct and then immediately
astExempt an object in one thread, and then astAnnul it later 
in some other thread?  I scarcely use astBegin/astEnd in JNIAST,
so astExempting is no hardship.  Or would this still incur 
unpredictable behaviour?

If not, the only other solution that springs to mind is to have
a dedicated thread which does all AST object construction and annulment
- it would be profoundly un-Java to require library users to call
an annul method in the same thread as object construction happened.
I'd have thought that other libraries and even applications making
non-trivial use of threading in AST would need to end up doing 
something similar.  It would be possible to implement something
along these lines (I think), but it does seem like a surprisingly 
complicated way to have to do it.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/