Sorry for the delay chaps - I'm trying to remind myself of how all
this works, and why I wrote the bits of text that Mark is questioning.
My current suspicion is that the bits of text were left over from a
earlier stab at thread-safe AST that worked differently to the final
version. I'll be back when I have a definitive answer...
David
2009/1/22 Peter W. Draper <[log in to unmask]>:
> On Thu, 22 Jan 2009, Mark Taylor wrote:
>
>> 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,
>
> while waiting for an authoritative response from David...
>
> I think the reason this should be OK for us is just that we synchronise all
> calls to AST, so only one thread can be running AST code at any time. Since
> astUnlock exports the object context from the thread, all the mucking about
> with contexts should still be unnecessary.
>
> However, when I last read all this I assumed David was worrying about when
> more than one thread is running concurrently, but thinking about it more,
> shouldn't an astCopy be recommended in that case, rather than astClone? Or
> maybe the thought was that cloning allows a type of read-only sharing,
> without worrying who does the annul.
>
> Peter.
>
--
Note my change of e-mail address. Please send e-mail to
[log in to unmask] from now on.
|