Regression: Instability in parallel incmesh on Linux.

Looks like a regression of #0022850 issue.

Reproduced in CR23087_CR23210_master GIT repository.

The end file of mesh grid is updated in GIT. It will be necessary to delete TODO bloc for this problem after integration of fix.

Added protection to the function which may have data race (according to the valgrind report).

Fix pushed to the branch CR23260

Dear Andrey,
Please review.

Added protection for the BRep_Tool::PolygonOnTriangulation and BRep_Tool::UVPoints inside BRepMesh_FastDiscretFace::RestoreStructureFromTriangulation

Dear Andrey,
Please review

I have changed slightly the order of operators so as to lock mutex only once; no other remarks. Please test

The problem still exists in CR23273 heritable from CR23260.

Problem was that the Standard_Mutex::SentryNested were created as temporary objects. So they did not have any effect.

Fix has been pushed to the branch CR23260

Dear Andrey,
Please review.

No remarks, please test

We recognized that the fix does not work; the possible reason is that map of edges uses TopTools_ShapeMapHasher which accounts for the edge location, thus edges with different locations are considered different and do not get protected from the data race. The fix to be tried is to change the map to use the edge's TShape (which is Handle) instead of the whole Edge.

Map inside TopTools_MutexForShapeProvider now stores Handle_TopoDS_TShape as a key instead of TopoDS_Shape.

Changes have been pushed to the git.

Dear Andrey,
Please review.

No remarks, please test

Test cases mesh standard_incmesh_parallel R3 hangs up or performance is decreased (killed by cpulimit 1000).
Platforms are:
Debian40, Mandriva2008, SL51-64.

It is looks like a performance problem of stations. The incmesh is called 1000 times in circle for R3 case. The time for one incmesh call is about 1 second. cpulimit is set to 1000. It means the case may be killed by cputime if station has old processor.

I think the issue may be closed.

I tested the branch with a valgrind (helgrind tool was used). And now it doesn't report about any problems in occt code.

So I also think that the problem is finally fixed.

Dear Commenter 2,
The workbenches
KAS:dev:mkv-23260-occt (GIT branch CR23260)
KAS:dev:mkv-23260-products (GIT master)
were compiled on Linux platform and tested.

Regression:
Not detected

Improvements:
Not detected

Testing case:
Not needed

See results in /QADisk/occttests/results/KAS/dev/mkv-23260-products_18072012/lin
See reference results in /QADisk/occttests/results/KAS/dev/products-20120706-opt_06072012/lin
See test cases in /QADisk/occttests/tests/ED