Re: [certi-dev] Deadlock with jcerti

[Eric Noulard]

2012/10/11 Jan-Patrick Osterloh <address@hidden>:
> Hi Andrej,
>
> --- Quoted from Andrej Pancik (Date: 10.10.2012 21:41): ---
>>
>> did you try to run the code in the debug mode and stop the execution
>> as soon as it hangs to observe where exactly it happens?
>>
> Yes, I finally succeed in debugging. It finally hangs in
> MessageBuffer.receiveData(), line 303 in the inputStream.read();
> According to the JavaDoc of InputStream, this method blocks until new
> data is available. Maybe the sender is too fast and has send the data
> already, without being received?

I doubt it, this inputStream comes from the serverSocket.accept()
in CertiRtiAmbassafor.java:146 which accept a connection
from the rtia process that have been launched right before that.

This socket cannot "loose" data, this is a TCP socket, the sender (rtia)
would be blocked if the reader is not reading fast enough.

> That would explain why it works when I
> start the debugging into file (this would slow down the RTIA process...)?

I would rather have a look at rtia process initialization which "may" be racy
when several PrettyDebug instance are used for different threads
(1 for each federate).

When "CERTI_DEBUG_FILE" is not defined then they "share" std::cerr,
which may not be a very good idea since C++ standard I/O are not
guaranteed to be thread -safe:
http://stackoverflow.com/questions/6374264/is-cout-synchronized-thread-safe

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org