Archived issue #0031921
Application Framework - reading OCAF data from several threads is not possible
Description
When application starts several threads and tries to read some OCAF information from these threads independently, it's not safe.
It's caused by:
TDF_Label::FindChild(), which calls inside TDF_Label::FindOrAddChild(), that changes myLabelNode.
If possible, let's give some way to avoid data modification during reading it. It's fine, even if it is optional for document, application or other.
It's caused by:
TDF_Label::FindChild(), which calls inside TDF_Label::FindOrAddChild(), that changes myLabelNode.
If possible, let's give some way to avoid data modification during reading it. It's fine, even if it is optional for document, application or other.
Public activity
8 archived notes
Participants are labeled by their role within this record.
Branch [archived branch] has been created by Participant.
[revision removed]
Detailed log of new commits:
Author: mpv
Date: Mon Nov 16 16:49:23 2020 +0300
0031921: Application Framework - reading OCAF data from several threads is not possible
Make myLastFoundChild field of TDF_LabelNode that can be changed during accessing to different sub-labels in different threads as atomic (only for newer versions of compilers which support this "atomic").
[revision removed]
Detailed log of new commits:
Author: mpv
Date: Mon Nov 16 16:49:23 2020 +0300
0031921: Application Framework - reading OCAF data from several threads is not possible
Make myLastFoundChild field of TDF_LabelNode that can be changed during accessing to different sub-labels in different threads as atomic (only for newer versions of compilers which support this "atomic").
In TDF_LabelNode.hxx:
Definition of this kind of global macros should be not in particular class but in common place, e.g. Standard_Macro.hxx. The macro must have name sufficiently specific to avoid name clashes in real-world applications involving multiple libraries. "HAS_ATOMIC" is too simple. See how macros are named AND DOCUMENTED in Standard_Macro.hxx
#if (defined(__cplusplus) && __cplusplus >= 201100L) || (defined(_MSC_VER) && _MSC_VER >= 1800) || \
(defined(__GNUC__) && ((__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7)))
#define HAS_ATOMIC
#include <atomic>
#endif
Definition of this kind of global macros should be not in particular class but in common place, e.g. Standard_Macro.hxx. The macro must have name sufficiently specific to avoid name clashes in real-world applications involving multiple libraries. "HAS_ATOMIC" is too simple. See how macros are named AND DOCUMENTED in Standard_Macro.hxx
Branch [archived branch] has been updated by Participant.
[revision removed]
Detailed log of new commits:
Author: mpv
Date: Tue Nov 17 10:46:45 2020 +0300
Added definition of Standard_ATOMIC macro to the Standard_Macro.hxx
[revision removed]
Detailed log of new commits:
Author: mpv
Date: Tue Nov 17 10:46:45 2020 +0300
Added definition of Standard_ATOMIC macro to the Standard_Macro.hxx
Dear ABV,
Is it better now?
Is it better now?
The fixed problem is hypothetical, it is not reproduced neither in application nor in unit-tests (I've checked with different number of threads, number of sub-labels and different access to them), so, unit-test are useless.
No remarks, please integrate:
OCCT: branch CR31921 (to be squashed)
Products: nothing
OCCT: branch CR31921 (to be squashed)
Products: nothing
Combination -
OCCT branch : [archived branch]
master SHA - [revision removed]
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Regressions/Differences/Improvements:
No regressions/differences
CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18049.94000000008 / 18024.44000000013 [+0.14%]
Products
Total CPU difference: 12325.960000000132 / 12167.95000000011 [+1.30%]
Windows-64-VC14:
OCCT
Total CPU difference: 19703.46875 / 19697.21875 [+0.03%]
Products
Total CPU difference: 13792.6875 / 13647.203125 [+1.07%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention
OCCT branch : [archived branch]
master SHA - [revision removed]
[revision removed]
Products branch : [archived branch] SHA - [revision removed]
was compiled on Linux, MacOS and Windows platforms and tested in optimize mode.
Number of compiler warnings:
No new/fixed warnings
Regressions/Differences/Improvements:
No regressions/differences
CPU differences:
Debian80-64:
OCCT
Total CPU difference: 18049.94000000008 / 18024.44000000013 [+0.14%]
Products
Total CPU difference: 12325.960000000132 / 12167.95000000011 [+1.30%]
Windows-64-VC14:
OCCT
Total CPU difference: 19703.46875 / 19697.21875 [+0.03%]
Products
Total CPU difference: 13792.6875 / 13647.203125 [+1.07%]
Image differences :
No differences that require special attention
Memory differences :
No differences that require special attention
Branch [archived branch] has been deleted by Participant.
[revision removed]
[revision removed]
Related records