Hans,
Thanks for your detailed answer. I think I never encountered an event where
an exception was thrown in real life,
so as you suggest I'll go ahead and remove as needed.
Thanks,
Itaru.
On Thu, May 2, 2019 at 4:53 AM Hans Ekkehard Plesser <
hans.ekkehard.plesser(a)nmbu.no> wrote:
Dear Itaru,
Short answer: For experimental purposes, you can remove those try-catch
blocks and NEST will continue to work.
Longer answer:
Handling exceptions in multithreaded code is difficult in C++, since C++
does not support exception handling across threads, at least not when using
OpenMP threads. To handle potential exceptions safely, we therefore handle
exceptions inside each thread-parallel context, store them and then
re-throw them as soon as we reach a single-threaded context. This allows us
to provide proper error messages. If you remove the error-handling code and
an exception is thrown in a parallel context, NEST will crash, because the
exception is never caught.
Typical situations where such exceptions could occur is during parallel
connection if trying to make invalid connections, or when encountering
numerical instabilities, e.g. due to the exponential term in aeif neurons.
To ensure proper error handling in NEST, we need to keep the per-thread
error handling in the master branch, but for experimental purposes it can
be removed without changing the way NEST works.
Best,
Hans Ekkehard
> On 1 May 2019, at 07:33, Itaru Kitayama <itaru.kitayama(a)gmail.com>
wrote:
>
> Hans,
>
> Not limited to this part of code, though for example, we have in
nestkernle/simulation_manager.cpp
>
> [...]
> #pragma omp target teams distribute parallel for
> for(int i=0;i<len;i++)
> {
> // We update in a parallel region. Therefore, we need to catch
> // exceptions here and then handle them after the parallel
region.
> //try
> //{
> if ( not( *node )->is_frozen() )
> {
> ( *node )->update( clock_, from_step_, to_step_ );
> }
> //}
> /*catch ( std::exception& e )
> {
> // so throw the exception after parallel region
> exceptions_raised.at( tid ) = lockPTR< WrappedThreadException
>(
> new WrappedThreadException( e ) );
> }*/
> ++node;
> }
>
> OpenMP offload doesn't support exception handling on devices, so any
loop that can be offloadable, but
> contains exception handling, can we safely comment out?
>
> Itaru.
>
> On Tue, Apr 30, 2019 at 6:49 AM Hans Ekkehard Plesser <
hans.ekkehard.plesser(a)nmbu.no> wrote:
>
> Dear Itaru,
>
> Could you be more specific about where you would like to remove
exception handling code and why? In general, I would be rather reluctant to
remove exception handling code.
>
> Best,
> Hans Ekkehard
>
> > On 26 Apr 2019, at 13:56, Itaru Kitayama <itaru.kitayama(a)gmail.com>
wrote:
> >
> > Hi,
> > Am I able to safely comment out all those exception handling codes
provided
> > they're provided for the defensive purposes? I ask because I am trying
to
> > insert offloading directives into the NEST code base wherever I can.
> >
> > Thanks,
> > Itaru.
> > _______________________________________________
> > NEST Users mailing list -- users(a)nest-simulator.org
> > To unsubscribe send an email to users-leave(a)nest-simulator.org
>
> --
>
> Prof. Dr. Hans Ekkehard Plesser
> Head, Data Science Section
>
> Faculty of Science and Technology
> Norwegian University of Life Sciences
> PO Box 5003, 1432 Aas, Norway
>
> Phone +47 6723 1560
> Email hans.ekkehard.plesser(a)nmbu.no
> Home
http://arken.nmbu.no/~plesser
>
> _______________________________________________
> NEST Users mailing list -- users(a)nest-simulator.org
> To unsubscribe send an email to users-leave(a)nest-simulator.org
--
Prof. Dr. Hans Ekkehard Plesser
Head, Data Science Section
Faculty of Science and Technology
Norwegian University of Life Sciences
PO Box 5003, 1432 Aas, Norway
Phone +47 6723 1560
Email hans.ekkehard.plesser(a)nmbu.no
Home
http://arken.nmbu.no/~plesser