cds  2.3.2
cds::threading Namespace Reference

Threading support. More...


template<class GC >
GC::thread_gc_impl & getGC ()
 Returns thread specific data of GC garbage collector.
template<typename RCUtag >
cds::urcu::details::thread_data< RCUtag > * getRCU ()
 Returns RCU thread specific data (thread GC) for current thread. More...


size_t m_nFakeProcessorNumber
 fake "current processor" number
cds::algo::elimination::record m_EliminationRec
 Per-thread elimination record.

Detailed Description

Threading support.

The CDS library requires support from the threads. Each garbage collector manages a control structure on the per-thread basis. The library does not dictate any thread model. To embed the library to your application you should choose appropriate implementation of cds::threading::Manager interface or should provide yourself. The cds::threading::Manager interface manages cds::threading::ThreadData structure that contains GC's thread specific data.

Any cds::threading::Manager implementation is a singleton and it must be accessible from any thread and from any point of your application. Note that you should not mix different implementation of the cds::threading::Manager in your application.

Before compiling of your application you may define one of CDS_THREADING_xxx macro in cds/user_setup/threading.h file:

  • CDS_THREADING_AUTODETECT - auto-detect appropriate threading model for your platform and compiler. This is predefined value of threading model in cds/user_setup/threading.h.
  • CDS_THREADING_WIN_TLS - use cds::threading::wintls::Manager implementation based on Windows TLS API. Intended for Windows and Microsoft Visual C++ only. This is default threading model for Windows and MS Visual C++.
  • CDS_THREADING_MSVC - use cds::threading::msvc::Manager implementation based on Microsoft Visual C++ __declspec(thread) declaration. Intended for Windows and Microsoft Visual C++ only. This macro should be explicitly specified if you want to use __declspec(thread) keyword.
  • CDS_THREADING_PTHREAD - use cds::threading::pthread::Manager implementation based on pthread thread-specific data functions pthread_getspecific / pthread_setspecific. Intended for GCC and clang compilers. This is default threading model for GCC and clang.
  • CDS_THREADING_GCC - use cds::threading::gcc::Manager implementation based on GCC __thread keyword. Intended for GCC compiler only. Note, that GCC compiler supports __thread keyword properly not for all platforms and even not for all GCC version. This macro should be explicitly specified if you want to use __thread keyword.
  • CDS_THREADING_CXX11 - use cds::threading::cxx11::Manager implementation based on thread_local keyword introduced in C++11 standard. May be used only if your compiler supports C++11 thread-local storage.
  • CDS_THREADING_USER_DEFINED - use user-provided threading model.

These macros select appropriate implementation of cds::threading::Manager class. The child namespaces of cds::threading provide suitable implementation and import it to cds::threading by using using directive (or by using inline namespace if the compiler supports it). So, if you need to call threading manager functions directly you should refer to cds::threading::Manager class.

Usually, you should not use cds::threading::Manager instance directly. You may specify CDS_THREADING_xxx macro when building, everything else will setup automatically when you initialize the library, see How to use libcds.

The interface of cds::threading::Manager class is the following:

class Manager {
// Initialize manager (called by cds::Initialize())
static void init();
// Terminate manager (called by cds::Terminate())
static void fini();
// Checks whether current thread is attached to \p libcds feature or not.
static bool isThreadAttached();
// This method must be called in beginning of thread execution
// (called by ctor of GC thread object, for example, by ctor of cds::gc::HP::thread_gc)
static void attachThread();
// This method must be called in end of thread execution
// (called by dtor of GC thread object, for example, by dtor of cds::gc::HP::thread_gc)
static void detachThread();
// Get cds::gc::DHP thread GC implementation for current thread;
static gc::DHP::thread_gc_impl& getDHPGC();

The library's core (dynamic linked library) is free of usage of user-supplied cds::threading::Manager code. cds::threading::Manager is necessary for header-only part of CDS library (for cds::threading::getGC functions).

Each thread that uses libcds data structures should be attached to threading::Manager before using lock-free data structs. See How to use section for details

Note for Windows

When you use Garbage Collectors (GC) provided by libcds in your dll that dynamically loaded by LoadLibrary then there is no way to use __declspec(thread) declaration to support threading model for libcds. MSDN says:

  • If a DLL declares any nonlocal data or object as __declspec( thread ), it can cause a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes system failure whenever the code references the nonlocal __declspec( thread ) data. Because the global variable space for a thread is allocated at run time, the size of this space is based on a calculation of the requirements of the application plus the requirements of all the DLLs that are statically linked. When you use LoadLibrary, there is no way to extend this space to allow for the thread local variables declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if the DLL might be loaded with LoadLibrary.

Thus, in case when libcds or a dll that depends on libcds is loaded dynamically by calling LoadLibrary explicitly, you should not use CDS_THREADING_MSVC macro. Instead, you should build your dll projects with CDS_THREADING_WIN_TLS only.

Function Documentation

◆ getRCU()

template<typename RCUtag >
cds::urcu::details::thread_data<RCUtag>* cds::threading::getRCU ( )

Returns RCU thread specific data (thread GC) for current thread.

Template argument RCUtag is one of RCU tags

cds 2.3.2 Developed by Maxim Khizhinsky aka khizmax and other contributors 2007 - 2017
Autogenerated Sun Dec 31 2017 12:10:54 by Doxygen 1.8.13