View Issue Details

IDProjectCategoryView StatusLast Update
0031921Open CASCADEOCCT:Application Frameworkpublic2020-12-05 13:45
Reporternds Assigned Tobugmaster  
PrioritynormalSeverityminor 
Status closedResolutionfixed 
Product Version5.1.0 
Target Version7.6.0Fixed in Version7.6.0 
Summary0031921: Application Framework - reading OCAF data from several threads is not possible
DescriptionWhen 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.
TagsNo tags attached.
Test case numberNot required

Relationships

parent of 0031983 closedbugmaster Open CASCADE Samples - CSharp cannot be compiled "atomic<> is not supported by C++/CLI" 

Activities

git

2020-11-16 16:49

administrator   ~0096797

Branch CR31921 has been created by mpv.

SHA-1: 0b594f2e7fc3fff22378e973e1b645589210980d


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").

abv

2020-11-17 09:03

manager   ~0096809

In TDF_LabelNode.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

git

2020-11-17 10:46

administrator   ~0096819

Branch CR31921 has been updated by mpv.

SHA-1: 3751d5b21b4e4bee259e60b49ebacf3feb76d185


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

mpv

2020-11-17 10:48

developer   ~0096820

Dear ABV,

Is it better now?

mpv

2020-11-18 15:16

developer   ~0096884

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.

abv

2020-11-22 21:58

manager   ~0096995

No remarks, please integrate:
OCCT: branch CR31921 (to be squashed)
Products: nothing

bugmaster

2020-11-28 12:44

administrator   ~0097114

Combination -
OCCT branch : IR-2020-11-27
master SHA - 765e5bc192b506e546ba77d881d4929dc0f69b1a
a206de37fbfa0bf71bd534ae47192bbec23b8522
Products branch : IR-2020-11-27 SHA - 17b49a570b557fbeb7326a4adb10fa231b058aed
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

git

2020-11-28 13:05

administrator   ~0097136

Branch CR31921 has been deleted by inv.

SHA-1: 3751d5b21b4e4bee259e60b49ebacf3feb76d185

Related Changesets

occt: master b84b6721

2020-11-16 13:49:23

mpv


Committer: bugmaster Details Diff
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").

Added definition of Standard_ATOMIC macro to the Standard_Macro.hxx
Affected Issues
0031921
mod - src/Standard/Standard_Macro.hxx Diff File
mod - src/TDF/TDF_LabelNode.hxx Diff File

Issue History

Date Modified Username Field Change
2020-11-11 17:55 nds New Issue
2020-11-11 17:55 nds Assigned To => mpv
2020-11-16 16:49 git Note Added: 0096797
2020-11-16 18:09 utverdov Status new => assigned
2020-11-17 09:03 abv Note Added: 0096809
2020-11-17 10:46 git Note Added: 0096819
2020-11-17 10:48 mpv Note Added: 0096820
2020-11-17 13:46 kgv Product Version => 5.2.2
2020-11-17 13:48 kgv Product Version 5.2.2 => 5.1.0
2020-11-18 14:06 kgv Assigned To mpv => abv
2020-11-18 14:06 kgv Status assigned => feedback
2020-11-18 14:06 kgv Status feedback => resolved
2020-11-18 15:16 mpv Note Added: 0096884
2020-11-22 21:58 abv Note Added: 0096995
2020-11-22 21:58 abv Assigned To abv => bugmaster
2020-11-22 21:58 abv Status resolved => reviewed
2020-11-28 12:44 bugmaster Note Added: 0097114
2020-11-28 12:44 bugmaster Status reviewed => tested
2020-11-28 12:48 bugmaster Test case number => Not required
2020-11-28 12:59 bugmaster Changeset attached => occt master b84b6721
2020-11-28 12:59 bugmaster Status tested => verified
2020-11-28 12:59 bugmaster Resolution open => fixed
2020-11-28 13:05 git Note Added: 0097136
2020-12-05 13:39 bugmaster Relationship added related to 0031983
2020-12-05 13:45 kgv Relationship replaced parent of 0031983