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

Error when calling set_synapse_defaults with multiple threads #719

Closed
hakonsbm opened this Issue May 15, 2017 · 2 comments

Comments

Projects
None yet
4 participants
@hakonsbm
Contributor

hakonsbm commented May 15, 2017

After PR #704 a bug has been found with setting defaults for synapse models using multiple threads, making NEST crash. Because of this, the test test_connect_parameters.py causes a segmentation fault somewhat reliably on multi-core systems.

The problem arises because we are setting defaults in parallel using OpenMP. Using parallelization here is not necessary, and removing it will fix the issue.

@jougs

This comment has been minimized.

Show comment
Hide comment
@jougs

jougs May 22, 2017

Contributor

Is this problems fixed with the merge of #724? If yes, please close it. Otherwise please comment on what is still needed. Thanks!

Contributor

jougs commented May 22, 2017

Is this problems fixed with the merge of #724? If yes, please close it. Otherwise please comment on what is still needed. Thanks!

@hakonsbm

This comment has been minimized.

Show comment
Hide comment
@hakonsbm

hakonsbm May 22, 2017

Contributor

It turns out it is necessary to use parallelization after all, and the bug has been fixed by #724, so I'm closing this.

Contributor

hakonsbm commented May 22, 2017

It turns out it is necessary to use parallelization after all, and the bug has been fixed by #724, so I'm closing this.

@hakonsbm hakonsbm closed this May 22, 2017

@heplesser

This comment has been minimized.

Show comment
Hide comment
@heplesser

heplesser May 22, 2017

Contributor

Just a bit more information for future reference:

  • We need to set parameters in parallel in set_synapse_defaults() because models some models (eg STDPDopaConnection) need to register thread-specific information (replica of volume_transmitter) in the prototype for each thread; this works only if set_status() is called on the correct thread.
  • After we have ensured that all names are introduced into the global Name table in thread-serial context only, we do no longer need to protect defaults-setting in an omp critical region.
  • Setting the accessed_ flag in parameter dictionaries during parallel calls to set_status() can in principle lead to non-deterministic behavior, but the end result is well defined: before the set_status() call, all access flags are false, and the only thing that can happen is that an access flag is set to true. As long as a single thread sets the flag to true, all is well, so the behavior overall is deterministic. In the very worst case it could be conceivable that two threads writing true simultaneously lead to the flag remaining false, but that would at worst lead to an incorrect error message about a field not accessed, and thus is a safe form of failure. See also NESTML Issue 357 .
Contributor

heplesser commented May 22, 2017

Just a bit more information for future reference:

  • We need to set parameters in parallel in set_synapse_defaults() because models some models (eg STDPDopaConnection) need to register thread-specific information (replica of volume_transmitter) in the prototype for each thread; this works only if set_status() is called on the correct thread.
  • After we have ensured that all names are introduced into the global Name table in thread-serial context only, we do no longer need to protect defaults-setting in an omp critical region.
  • Setting the accessed_ flag in parameter dictionaries during parallel calls to set_status() can in principle lead to non-deterministic behavior, but the end result is well defined: before the set_status() call, all access flags are false, and the only thing that can happen is that an access flag is set to true. As long as a single thread sets the flag to true, all is well, so the behavior overall is deterministic. In the very worst case it could be conceivable that two threads writing true simultaneously lead to the flag remaining false, but that would at worst lead to an incorrect error message about a field not accessed, and thus is a safe form of failure. See also NESTML Issue 357 .
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment