Re: [Openrti-devel] "CallNotAllowedFromWithinCallback" exception

[Bonje F. <bon...@ou...>]

Hi Mathias


I hope that you have a great training period.


As last discussion that we have, I handled that exception(rti1516e::CallNotAllowedFromWithinCallback) *temporarily* by locking the evokeMultipleCallbacks method via a mutex. On the other hand by using a mutex let me that not only can I guarantee that there is no evokeMultipleCallbacks called simultaneously, but also those threads communicate with RTI consequently.


So, are you planing to add this feature[1] to the OpenRTI soon? If Yes, with respect to your solution of the problem: "... I need to put a mutex into the RTIambassador that serializes multiple invocations in the short term. In the long term some of them may be allowed concurrently...", I think this cannot be a good *permanent* solution, since it serializes the communication(as I mentioned, currently I do that in the federate side). I think it is an important feature that lets data could be exchanged concurrently.


Kind regards

Bonje


---------------------------------------------

[1] - [HLA Standard Paper] [section 12.6] - 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.

________________________________
From: Mathias Fröhlich <Mat...@gm...>
Sent: Tuesday, September 19, 2017 3:12:02 AM
To: Bonje Fir
Cc: ope...@li...
Subject: Re: "CallNotAllowedFromWithinCallback" exception

Hi,

On Sunday, 17 September 2017 16:03:11 CEST Bonje Fir wrote:
> I found following note in the standard paper [section 12.6 Concurrency and
reentrancy]:
>
> "...
>
>     - 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.
>
> "
>
> Which I think it is opposite of your note(we must able to call
evokeMultipleCallbacks from different threads with the same RTIambassador).
Also I found this note(maybe it can help):
>
>
> "...
>
>     - 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.
>
> "

Indeed, that paragraph is new in rti1516e since the previous rti1516 binding.
I missed that paragraph so far.

> What is your opinion/suggestion/idea? 😊

Thats three questions now:

Idea: Pretty obvious - I need to put a mutex into the RTIambassador that
serializes multiple invocations in the short term. In the long term some of
them may be allowed concurrently.

Suggestion: Wait until I find time to do that. At least until I have all the
documents at hands.

Opinion: Well - sad that the makers of the standard did this as it requires a
mutex type thing in the service invocation path. Currently I have just one
mutex that is pretty lightweight only locking while inserting messages into
the output queue. And that queue may have been replaced with something
lockless in the very far term. But now the best we can end with is a multiple
read - single write lock in the fast path service invocations sending
messages. Something similar - hammering with multiple threads onto an
ambassador - can probably be achieved with more federates.

Let me think about that if I find some lightweight idea.

best

Mathias