Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parallelization bug #23 and cmake_constant_file #27

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

MartKro
Copy link

@MartKro MartKro commented Jan 14, 2020

  • Fixed the parallelization bug Parallelization with RELIC #23 which prevents possible parallelization due to the introduced mutex. Now the mutex is also protected using __thread but since it is implementation dependent the flag can be easily disabled
  • Changed the introduction of constants from CMAKE to an extra file cmake_constants.h.in

- Fixed the parallelization bug which prevents possible parallelization due to the introduced mutex. Now the mutex is also protected using __thread but since it is implementation dependent the flag can be easily disabled
- Changed the introduction of constants from CMAKE to an extra file cmake_constants.h.in

Signed-off-by: Martin Kromm <[email protected]>
static std::mutex relic_mutex;
#endif
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if multithreading via pthreads is enabled in Relic, then you give every thread its own mutex in thread local storage. Hence, every thread locks its own mutex to access its own relic context object (also in TLS). I do not see the need for this mutex then.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've already considered it to disable the mutex completely if the preprocessor flag is defined (and this was done in a previous implementation of mine). However after some considerations I decided against it since the method only enables thread safety for a single thread method; that is, if a user decides to use pthread but then also uses openmp concurrently thread safety cannot be guranteed then, and it is not obvious to see for a user if he doesn't study the code.

I rather prefer to implement concurrency conserative since errors are often easy to make and hard to find later. Besides that there speaks nothing against your suggestion.

@codedust
Copy link

This doesn't introduce thread local mutexes when using OpenMP, right? Could you also declare the mutex threadprivate if OpenMP is enabled? (like it's done here with the context object: https://github.com/relic-toolkit/relic/blob/c25edf6520e5e4b39663f0d0594db7186440be5c/src/relic_core.c#L95)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants