Wed 01 Jun 2011 05:50:59 PM UTC, comment #7:
>> In fact the design of the RTI API makes it
>> essentially non-reentrant so there wouldn't currently
>> be much benefit to enable thread safety.
> If there is no benefits in internal RTI mutex, there are really
> no reasons to integrate it =). Still it would be great to see
> this information somewhere in the project documentation.
Thas was a little bit black/white judgement of mine.
Some services may be called several time at once
(or in a re-entrant way) but some may not.
The main troubles mainly comes from the callback/tick/evoke
mechanism.
Imagine two threads of the same process are calling two differents
services like SubscribeInteractionClass and
QueryAttributeOwnership then normally both
thread will go to tick/evoke and wait for the corresponding
callback.
How can we ensure that the appropriate thread will get
the appropriate callback during its tick ?
You either need some kind of serialization or accepting
that each thread is a known [unique] LP to the RTI.
More trouble comes if the two threads are trying to
call mutually exclusive services like TAR and NERA for example.
HLA 1.3 document and IEEE-1516-2000 do not even mention
concurrency/reentrance.
The latest IEEE-1516-2010 does (ยง12.6 Concurrency and reentrancy)
here is an excerpt:
_The following requirements apply to an RTI:
- The RTI shall not make concurrent RTI-initiated service invocations to the same FederateAmbassador instance.
- The RTI shall support concurrent joined federate-initiated service invocations to the same RTIambassador instance. The service invocations shall be processed, in parallel or sequentially.
- When in EVOKED mode, all RTI-initiated service invocations shall be made using the same thread context that was used in the invocation of the Evoke Callback/Evoke Multiple Callbacks service.
- The RTI shall support concurrent joined federate-initiated service invocations to different RTIambassador instances. The calls shall be processed, in parallel or sequentially.
- An RTIambassador instance shall be capable of creating concurrent federation executions.
- The RTI shall support invocation by a joined federate of a subset of joined federate-initiated services from within the context of an RTI-initiated service invocation on the same joined federate. Invocation of joined federate-initiated services not within this subset shall generate the Call Not Allowed From Within Callback exception. The allowed subset of joined federate-initiated services is all joined federate-initiated services except Connect, Disconnect, Join Federation Execution, Resign Federation Execution, Evoke Callback, and Evoke Multiple Callbacks._
So in the end we *should* (this is not the case today)
support concurrent calls but we may decide to sequentialize those calls. We could use a big single mutex in each libRTI call however since we *must* (this is the case today) support
reentrant call to federate-initiated service from within a callback (RTI-initiated service) we would at least need to use reentrant mutex.
Finally, this is a interesting question but not as easy as it seem in the first place...
This is definitely not in the short-time plan :-(
But as always, patches are welcome :-]
|