Threaded timers break GetConnections()

[heplesser]

A NEST built with -Dwith-detailed-timers=ON -Dwith-threaded-timers=ON will trigger a failing assertion upon the following:

python -c "import nest ; nest.local_num_threads = 2 ; nest.GetConnections()"   

The assertion is triggered by the call to is_source_table_cleared() here:

nest-simulator/nestkernel/connection_manager.cpp

Line 1227 in 5fd75c0

if ( is_source_table_cleared() )

, which is called in a serial context. With a few intermediate steps, this calls PerThreadBoolIndicator::all_true() here:

nest-simulator/nestkernel/per_thread_bool_indicator.cpp

Line 82 in 5fd75c0

PerThreadBoolIndicator::all_true() const

, which in turn starts a stopwatch.

This all happens in a serial context. But threaded timers require that they be started and stopped in a thread-parallel context, see

nest-simulator/nestkernel/stopwatch_impl.h

Line 36 in 5fd75c0

kernel().vp_manager.assert_thread_parallel();

.

The idea behind the assertion was that threaded timers would only be started/stopped from parallel contexts. But the all/any_true/false() methods may be called from serial and parallel contexts, and then the timers in them need to support this.

So I think we should remove the assertions from the start() and stop() methods, as well as from is_running() and elapsed(). If called from a serial context, the time would be for thread 0.

For print() I am uncertain what would be the best choice and implementation, but thread-parallel writing to an ostream does not seem optimal.

[JanVogelsang]

Isn't this a duplicate of #3442 which will be fixed by #3445?

[heplesser]

@JanVogelsang You are right, I should have remembered that! I will close this one and adjust the title of #3442 to include the threaded timers.