On 02/10/2012 09:33, Jaroslav Bachorik wrote:
:
The generated TIE class is inherently thread-unsafe. The internal state
(the target field) can be manipulated without any enforced
synchronization - eg. it is valid to set the target field to null by
calling the deactivate() method after the _invoke() method has been
entered from a different thread. This will lead to the NPE we can
observe. Given this example one should make critical sections out of
deactivate() and _invoke() methods to prevent this situation. However,
this simplistic approach might lead to deadlocks in the existing code
as the _invoke() method body might be blocking (it is a 3rd party code)
and thus preventing execution of the deactivate() method indefinitely.
Also, it is not really possible to solve this problem outside of the
generated TIE class - it is caused by the concurrent change of the
TIE's internal state. So, the solution would be either caching the
target attribute at the beginning of the invoke() operation in a
synchronized block and use the cached version afterwards (and throwing
a remote exception if it is null - the TIE was deactivated effectively
before entering the invoke() operation) or postponing deactivation when
the invoke() method is detected as being in progress.
-JB-
Jaroslav and I chatted on IM about this today. Jaroslav is going to have
a go at changing the stub generator and will send a follow-up mail with
an updated webrev (this time for the corba repo as the that is where the
stub generator lives).
-Alan
