artem-ogre / CDT

Constrained Delaunay Triangulation (C++)
https://artem-ogre.github.io/CDT/
Mozilla Public License 2.0
1.08k stars 136 forks source link

Random shuffling isn't thread-safe and may cause issues with the linker #97

Closed here-abarany closed 1 year ago

here-abarany commented 2 years ago

The current random shuffling that's enabled by default declares a static mt19937 randGenerator(9001) in Triangulation.h. By declaring the variable as static, this has two main effects:

  1. The variable will be shared across threads. This means that performing multiple Delaunay operations across different threads will interfere with the shuffling, and in worst case could break the random number distribution in the generator as the state is updated unsafely.
  2. A separate instance will be created in each .cpp file that includes Triangulation.h. If this happens in multiple .cpp files in a library, I'm not quite sure what would happen when the linker removes duplicate template instantiations that refer to the randGenerator object.

One option is to avoid a global object and create a stack object instead. Given that you're re-seeding randGenerator each time this would have the same performance. randGenerator will be ~2.5 KB for its internal state, but this cost could be mitigated by moving the instance to the random_shuffle() function so it's popped off the stack before any recursive operations occur.

A couple other things worth noting:

artem-ogre commented 2 years ago

Thanks for opening the issue @here-abarany. I will take a closer look when I’m back at the keyboard.

here-abarany commented 2 years ago

@artem-ogre what are your plans for the changes on the 97-use-splitmix64-prng branch? I noticed that some of the tests are failing, presumably the "ground truth" tests are sensitive to the different shuffle order. Is it just a matter of finding the time to fix up the tests and any remaining cleanup, or are there other concerns that need to be investigated first?

artem-ogre commented 2 years ago

@artem-ogre presumably the "ground truth" tests are sensitive to the different shuffle order

yes, in situations of polygons formed by concyclic points different vertex insertion order can produce different (but still correct) triangulation. Easy way to fix tests is to visually verify that triangulations are still correct and then regenerate the ground truth. But I had in mind solving this by detecting concyclic polygons and producing a unique triangulation. This would make tests less fragile. But this is a significant effort I did not find time for yet.

here-abarany commented 2 years ago

Does this mean that using randomized vs. unrandomized inputs should give the same results? If so that's definitely something we'd be very interested in.

here-abarany commented 2 years ago

Hi, I noticed that some work was done on this with the new-insertion-sequence branch. Do you have any updates on the status of that and when you might think it could be considered "done" and merged into master?

artem-ogre commented 2 years ago

@here-abarany Yes, the branch is almost ready, but I still need to test and investigate some corner-cases that are different. Random generator change is a part of this branch.

Unfortunately, I have very little spare time to dedicate to CDT. I can't commit on any deadline, but I try my best.

here-abarany commented 2 years ago

Cool, thanks for the update.

artem-ogre commented 2 years ago

Related: #112

artem-ogre commented 1 year ago

Fixed.