Classes | Public Types | Public Member Functions | Static Public Member Functions | Static Private Attributes | List of all members
stan::math::AutodiffStackSingleton< ChainableT, ChainableAllocT > Struct Template Reference

#include "stan/math/rev/core/autodiffstackstorage.hpp"

Classes

struct  AutodiffStackStorage
 

Public Types

typedef AutodiffStackSingleton< ChainableT, ChainableAllocT > AutodiffStackSingleton_t
 

Public Member Functions

 AutodiffStackSingleton ()=delete
 
 AutodiffStackSingleton (AutodiffStackSingleton_t const &)=delete
 
AutodiffStackSingletonoperator= (const AutodiffStackSingleton_t &)=delete
 

Static Public Member Functions

static AutodiffStackStorageinstance ()
 

Static Private Attributes

static AutodiffStackStorage instance_
 

Detailed Description

template<typename ChainableT, typename ChainableAllocT>
struct stan::math::AutodiffStackSingleton< ChainableT, ChainableAllocT >

Provides a thread_local singleton if needed. Read warnings below! For performance reasons the singleton is a global static for the case of no threading which is returned by a function. This design should allow the compiler to apply necessary inlining to get maximal performance. However, this design suffers from "the static init order fiasco"[0]. Anywhere this is used, we must be absolutely positive that it doesn't matter when the singleton will get initialized relative to other static variables. In exchange, we get a more performant singleton pattern for the non-threading case. In the threading case we use the defacto standard C++11 singleton pattern relying on a function wrapping a static local variable. This standard pattern is expected to be well supported by the major compilers (as its standard), but it does incur some performance penalty. There has been some discussion on this; see [1] and [2] and the discussions those PRs link to as well.

These are thread_local only if the user asks for it with -DSTAN_THREADS. This is primarily because Apple clang compilers before 2016 don't support thread_local and the additional performance cost. We have proposed removing support for those[3], and at that time we should evaluate the performance of a switch to thread_local. If there is no loss in performance, we can remove this ifdef.

[0] https://isocpp.org/wiki/faq/ctors#static-init-order [1] https://github.com/stan-dev/math/pull/840 [2] https://github.com/stan-dev/math/pull/826 [3] http://discourse.mc-stan.org/t/potentially-dropping-support-for-older-versions-of-apples-version-of-clang/3780/

Definition at line 42 of file autodiffstackstorage.hpp.

Member Typedef Documentation

template<typename ChainableT , typename ChainableAllocT >
typedef AutodiffStackSingleton<ChainableT, ChainableAllocT> stan::math::AutodiffStackSingleton< ChainableT, ChainableAllocT >::AutodiffStackSingleton_t

Definition at line 44 of file autodiffstackstorage.hpp.

Constructor & Destructor Documentation

template<typename ChainableT , typename ChainableAllocT >
stan::math::AutodiffStackSingleton< ChainableT, ChainableAllocT >::AutodiffStackSingleton ( )
delete
template<typename ChainableT , typename ChainableAllocT >
stan::math::AutodiffStackSingleton< ChainableT, ChainableAllocT >::AutodiffStackSingleton ( AutodiffStackSingleton_t const &  )
explicitdelete

Member Function Documentation

template<typename ChainableT , typename ChainableAllocT >
static AutodiffStackStorage& stan::math::AutodiffStackSingleton< ChainableT, ChainableAllocT >::instance ( )
inlinestatic
template<typename ChainableT , typename ChainableAllocT >
AutodiffStackSingleton& stan::math::AutodiffStackSingleton< ChainableT, ChainableAllocT >::operator= ( const AutodiffStackSingleton_t )
delete

Member Data Documentation

template<typename ChainableT , typename ChainableAllocT >
AutodiffStackSingleton< ChainableT, ChainableAllocT >::AutodiffStackStorage stan::math::AutodiffStackSingleton< ChainableT, ChainableAllocT >::instance_
staticprivate

The documentation for this struct was generated from the following file: