Closed brutzman closed 8 months ago
Problem definition:
Any performance reduction from synchronization is miniscule in comparison to possible loss of object integrity. Indeed synchronization blocking only occurs if it is needed. If we inadvertently create a deadlock, that will certainly be discovered as part of our extensive version-controlled unit tests and example applications - further fine-tuning can then occur.
Next steps:
FixedAndVariableDatumRoundTripTest is now fixed (Issue #26)
@terry-norbraten has also fixed some unnecessary duplicate creation of DISThreadedNetworkInterface instance in PduRecorder, further helping with threading.
We are looking pretty good, and so closing.
Found an interesting problem in DisThreadedNetworkInterface.selfTest() method where ESPDU changes to marking values were getting clobbered during fast sends/updates. This was shown by print statements showing the same marking value in rapid progression (rather than marking 1, marking 2, etc.).
Avoided this problem (for now) by creating a new PDU each time. I think this anomaly indicates that the library isn't fully thread safe, e.g. an ESPDU instance might get modified while still being sent (or reported upon). Some more thought will be needed for making all PDU methods thread safe.
Log of test results found in DisThreadedNetworkInterfaceSelfTestLog.txt