I updated my CERTI repository to the
current CVS version. Running CMake gave me the following error:
Check for working CXX compiler using: Visual Studio 8
2005
CMake Error: The source directory "OUTPUT_VARIABLE"
does not exist.
Specify --help for usage, or press the help
button on the CMake GUI.
CMake Error: Internal CMake error, TryCompile
configure of cmake failed
Check for working CXX compiler using: Visual Studio 8
2005 -- broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "cl" is not able
to compile a simple test program.
It fails with the following output:
CMake will not be able to correctly generate
this project.
Call Stack (most recent call first):
CMakeLists.txt:1 (PROJECT)
Configuring incomplete, errors occurred!
Do you have an idea what the problem
is?
Thanks,
Michael
Dipl.-Inform. Michael Raab
Fraunhofer-Institut für Fabrikbetrieb und -automatisierung IFF
Virtuell Interaktives Training
Sandtorstr. 22, 39106 Magdeburg, Germany
Telefon +49 (0) 391/ 40 90 122
Telefax +49 (0) 391/ 40 90 115
address@hidden http://www.iff.fraunhofer.de
oder http://www.vdtc.de
Von:
Michael Raab <address@hidden>
An:
CERTI development discussions
<address@hidden>
Datum:
05.06.2012 17:43
Betreff:
Re: [certi-dev]
CERTI deadlock
Gesendet von:
address@hidden
Hi Eric.
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 ?