Concurrently readable lazy-evaluated number type in CGAL

[tfmk]

Hello, does CGAL provide a working (maybe experimental?) lazy-evaluated number type that allows concurrent read operations? I asked this question in libigl/libigl#1339 and it seems that I'm not the only one with this requirement.

The program I'm working on could benefit from parallelization (potentially a 2x speedup), but when using Kernel<CGAL::Lazy_exact_nt> or CGAL::Epeck, I've noticed that concurrent read operations cause data races and crash the program.

I've tried using the number type mpq_class (as mentioned in #2685), which does not use lazy evaluation nor reference counting. As a result, the program runs without data races, but much slower.

I've also tried cloning Laurent Rineau's branch implementing Thread_safe_epeck (https://github.com/lrineau/cgal/tree/Filtered_kernel-Epeck_reentrance-GF). The code does compile and it seems that for simple inputs everything works perfectly. However, when I tried to process slightly bigger inputs (~3000 vertices), the program will sometimes crash. Is this a known issue? Maybe I'm doing something wrong - I could elaborate in another issue if that would be appropriate. Anyway, I want to thank Laurent for his effort in implementing a thread-safe epeck, I very much appreciate the work.

[lrineau]

Thanks @tfmk for trying my branch. I have not tested the branch a lot. Are you allowed to share your code and data? I would like to reproduce the crash you have and try to fix it.

(Related to #648).

[gdamiand]

I also tested this branch and I also observed some crash.

@lrineau I can share my prog with you if you want (but this is a big program complicated...).

[tfmk]

@lrineau I will certainly post more details, but first I'll try to create a minimal crashing version of the program (currently there's a lot of code).

[gdamiand]

@lrineau I tried to create a minimal example

https://gist.github.com/gdamiand/530700bb8640ecf6a502b312a7fccab3

[mglisse]

@gdamiand That example doesn't make much sense to me. First, it doesn't compile. Second, it is not supposed to finish but just fill your memory until it gets killed. Third, you detach all the threads, so we quickly reach the end of main, points gets destructed, and the threads that have a reference to it are unhappy. That all seems unrelated to Epeck.
Are there good tests for parallel Epeck tasks?

[gdamiand]

@gdamiand That example doesn't make much sense to me. First, it doesn't compile.

It does (I just tested it). You need CGAL master.

Second, it is not supposed to finish but just fill your memory until it gets killed.

I don't care about terminaison, since the program crash.

Third, you detach all the threads, so we quickly reach the end of main, points gets destructed, and the threads that have a reference to it are unhappy. That all seems unrelated to Epeck.
Are there good tests for parallel Epeck tasks?

I just updated the gist, to remove this detach. I also updated my example to allow to change between EPECK and EPICK (cf the gist).

When running the code with EPECK, it crashes, while it works with EPICK.

[mglisse]

Thank you for the updated test.
[please ignore what I had written before]

[gdamiand]

Indeed there is no concurent writting.
I only need to evaluate the same value in different threads.