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"


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] [1] [2] [3]

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 ( )
template<typename ChainableT , typename ChainableAllocT >
stan::math::AutodiffStackSingleton< ChainableT, ChainableAllocT >::AutodiffStackSingleton ( AutodiffStackSingleton_t const &  )

Member Function Documentation

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

Member Data Documentation

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

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