2009/1/22 Mark Taylor <[log in to unmask]>:
> 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.
Fortunately, it's not true. My initial stab at thread safety in AST
did not allow objects to be moved between threads. I think the text is
left over from then. I'll change it. The attached (awful, you don't
need to tell me) program shows that context levels do in fact work
within a multi-threaded application.
> 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?
It should be ok so long as you do the appropriate locking and
unlocking. See the attached prog.
> 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.
I'm hoping the code does what you want even if the docs need a little
attention. I'll re-write that section.
David
|