Filtered kernel: Epeck reentrance

[lrineau]

Add re-entrance to the CGAL::Epeck kernel.

• Use atomic types in <CGAL/Handle_for.h>,
• Use a mutex in <CGAL/Lazy.h>.

Depends on #642.

Fixes #4340.

[lrineau]

Merged in CGAL-4.8-Ic-102

[sloriot]

Merged in CGAL-4.8-Ic-104

[lrineau]

I have marked the PR with "not yet approved" because I want the PR to be tested in integration, but not merged in master yet. We have to do benchmarks before.

[lrineau]

Merged in CGAL-4.8-Ic-105.

[sloriot]

I think this branch is responsible for many warnings about c++11.
For example:
warning: variadic templates only available with -std=c++11 or -std=gnu++11

[lrineau]

Actually I do not think so. The issue seems to be because I was using g++-4.5.3 with an Boost library version compiled with g++-4.8.

[lrineau]

Commits
lrineau@6206c0c and
lrineau@8d83f01 fix the headers with Boost<1.53.

[lrineau]

Merged in CGAL-4.8-Ic-106.

[sloriot]

Merged in CGAL-4.8-Ic-107

[sloriot]

Fails on platforms 21, 22 and 24.

[luckyrantanplan]

Hi Laurent,
I really hope you will be able to merge this PR soon !
Cheers,

[lrineau]

I have refreshed the branch: merged it with master to solve the conflicts. I plan to work on it this week, during the CGAL developers meeting.

So far, the update of Lazy objects is done using a lock on a mutex. The bad thing is that all readers and writers have to lock the mutex. I have two other ideas, that might be more efficient:

• have a shared mutex, to have multiple readers and one exclusive writer,
• or using a pair of atomic<double> in Interval_nt (and 128 bits atomic operations in case SSE is used).

Both three variants will have to be benched, plus master.

[mglisse]

or using a pair of atomic<double> in Interval_nt (and 128 bits atomic operations in case SSE is used).

Modifying Interval_nt so that all operations are atomic seems like overkill that will badly affect the performance of approximate functors. We only want load/store of approximate objects in Lazy to be atomic-ish (it is not obvious if we will hit bugs if we keep it non-atomic).

Both three

2 = 3 ? 😕

[mglisse]

@lrineau The PoC branch https://github.com/mglisse/cgal/tree/mt-glisse seems to have less overhead than this one currently does. (it is messy, several ideas are not prototyped yet, etc, it is to get an idea of what a reasonable overhead looks like)

[lrineau]

@lrineau The PoC branch https://github.com/mglisse/cgal/tree/mt-glisse seems to have less overhead than this one currently does. (it is messy, several ideas are not prototyped yet, etc, it is to get an idea of what a reasonable overhead looks like)

That is indeed very interesting. What are the next steps, now?

[mglisse]

What are the next steps, now?

I don't know, some possible next steps

• experiment with some of the ideas I mention in various comments
• run the complete testsuite
• benchmark on programs that use construction and currently spend a significant amount of time in update_exact (suggestions?)
• also check memory use during benchmark
• write a test (for validity) and a benchmark with parallelism and a significant amount of contention
• use that benchmark to determine what variant is faster
• benchmark also on windows (and mac?), things like call_once could have wildly different behavior
• test on non-x86 hardware (memory ordering on x86 is special, and thread sanitizer only goes so far)
• eventually, clean things up and make the whole thing optional (behind macros or tags or something)

[lrineau]

Replaced by #5402.