first of all: Do you think it is worth
to download the recent CVS version of CERTI source code? Any major improvements/fixes
during the last half year?
> This code seems multithreaded.
> Do you have multiple thread accessing RTIambassador object concurrenlty?
> If this is the case, this is currently not supported by CERTI. > You may
use multithreaded code but currently the federate have to ensure
> that no concurrent access to RTIambassador is done.
I think concurrent access is prohibited
by our code. This should be fine...
> When your federation is stucked, are your active
federate stuck in this loop?
A little bit hard to predict as I can't look into the library, but I would
say yes...
>Other questions:
>Are you using 1.3 or 1516 interface?
1.3 interface
> What are the value of the lookahead of your active federates?
Lookahead is 60
> When you finally kill the stucked federation what are the messages
statistics
> of each RTIA in terms of number of messages?
> (in particular what is the number of NULL messages)
Recently we are running a no-console version of RTIA. Tomorrow I will build
a new version including console...
> Could you try to run with
> CERTI_USE_NULL_PRIME_MESSAGE_PROTOCOL set to ON ? Will do tomorrow....
Thanks,
Michael
Von:
Eric Noulard <address@hidden>
An:
CERTI development discussions
<address@hidden>
Datum:
05.06.2012 17:25
Betreff:
Re: [certi-dev]
CERTI deadlock
Gesendet von:
address@hidden
2012/6/5 Michael Raab <address@hidden>:
> Hello Eric,
>
> please find attached the code snippets. Passive federate code is copied
from
> my application.
> Active federate code is included in another library to which I do
not have
> access at the moment, but I think the attached code should fit the
library
> implementation.
>
> Passive Observer:
> while (true)
> {
> this->_rtiAmb->tick(0.1f, 0.5f);
>
> RTIfedTime mnet;
> this->_rtiAmb->queryLBTS(mnet);
>
> // update progress...
>
> Thread.Sleep(10);
> }
This code seems multithreaded.
Do you have multiple thread accessing RTIambassador object concurrenlty?
If this is the case, this is currently not supported by CERTI.
You may use multithreaded code but currently the federate have to ensure
that no concurrent access to RTIambassador is done.
> //////////////////////////////////////////////////////
>
> Active Federate:
> while (true)
> {
> // query simulations next event time
> float nextTime = this->getNextTime();
>
> RTIfedTime reqTime( nextTime );
> this->_rtiAmb->nextEventRequest( reqTime );
> this->_nextEventRequestPending = true;
I would have set "this->_nextEventRequestPending" to true
**before** sending the NER but this shouldn't be an issue
unless another thread using the same RTIA is ticking concurrently
in that case you will have a race on "this->_nextEventRequestPending".
When your federation is stucked, are your active federate stuck in this
loop?
Other questions:
Are you using 1.3 or 1516 interface?
What are the value of the lookahead of your active federates?
When you finally kill the stucked federation what are the messages statistics
of each RTIA in terms of number of messages?
(in particular what is the number of NULL messages)
Could you try to run with
CERTI_USE_NULL_PRIME_MESSAGE_PROTOCOL set to ON ?