2016-02-10 00:12:00 +01:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
2017-07-16 01:03:42 +02:00
|
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
|
|
// (found in the LICENSE.Apache file in the root directory).
|
2014-02-26 02:47:37 +01:00
|
|
|
//
|
|
|
|
// Copyright (c) 2011 The LevelDB Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file. See the AUTHORS file for names of contributors.
|
|
|
|
|
|
|
|
#include "util/thread_local.h"
|
|
|
|
#include "util/mutexlock.h"
|
2014-02-27 20:38:55 +01:00
|
|
|
#include "port/likely.h"
|
2015-01-12 18:59:36 +01:00
|
|
|
#include <stdlib.h>
|
2014-04-23 03:38:10 +02:00
|
|
|
|
2020-02-20 21:07:53 +01:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2014-02-26 02:47:37 +01:00
|
|
|
|
2017-02-02 23:02:41 +01:00
|
|
|
struct Entry {
|
|
|
|
Entry() : ptr(nullptr) {}
|
|
|
|
Entry(const Entry& e) : ptr(e.ptr.load(std::memory_order_relaxed)) {}
|
|
|
|
std::atomic<void*> ptr;
|
|
|
|
};
|
|
|
|
|
|
|
|
class StaticMeta;
|
|
|
|
|
|
|
|
// This is the structure that is declared as "thread_local" storage.
|
|
|
|
// The vector keep list of atomic pointer for all instances for "current"
|
|
|
|
// thread. The vector is indexed by an Id that is unique in process and
|
|
|
|
// associated with one ThreadLocalPtr instance. The Id is assigned by a
|
|
|
|
// global StaticMeta singleton. So if we instantiated 3 ThreadLocalPtr
|
|
|
|
// instances, each thread will have a ThreadData with a vector of size 3:
|
|
|
|
// ---------------------------------------------------
|
2020-07-15 18:21:57 +02:00
|
|
|
// | | instance 1 | instance 2 | instance 3 |
|
2017-02-02 23:02:41 +01:00
|
|
|
// ---------------------------------------------------
|
|
|
|
// | thread 1 | void* | void* | void* | <- ThreadData
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | thread 2 | void* | void* | void* | <- ThreadData
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | thread 3 | void* | void* | void* | <- ThreadData
|
|
|
|
// ---------------------------------------------------
|
|
|
|
struct ThreadData {
|
2017-11-03 22:32:00 +01:00
|
|
|
explicit ThreadData(ThreadLocalPtr::StaticMeta* _inst)
|
|
|
|
: entries(),
|
|
|
|
next(nullptr),
|
|
|
|
prev(nullptr),
|
|
|
|
inst(_inst) {}
|
2017-02-02 23:02:41 +01:00
|
|
|
std::vector<Entry> entries;
|
|
|
|
ThreadData* next;
|
|
|
|
ThreadData* prev;
|
|
|
|
ThreadLocalPtr::StaticMeta* inst;
|
|
|
|
};
|
|
|
|
|
|
|
|
class ThreadLocalPtr::StaticMeta {
|
|
|
|
public:
|
|
|
|
StaticMeta();
|
|
|
|
|
|
|
|
// Return the next available Id
|
|
|
|
uint32_t GetId();
|
|
|
|
// Return the next available Id without claiming it
|
|
|
|
uint32_t PeekId() const;
|
|
|
|
// Return the given Id back to the free pool. This also triggers
|
|
|
|
// UnrefHandler for associated pointer value (if not NULL) for all threads.
|
|
|
|
void ReclaimId(uint32_t id);
|
|
|
|
|
|
|
|
// Return the pointer value for the given id for the current thread.
|
|
|
|
void* Get(uint32_t id) const;
|
|
|
|
// Reset the pointer value for the given id for the current thread.
|
|
|
|
void Reset(uint32_t id, void* ptr);
|
|
|
|
// Atomically swap the supplied ptr and return the previous value
|
|
|
|
void* Swap(uint32_t id, void* ptr);
|
|
|
|
// Atomically compare and swap the provided value only if it equals
|
|
|
|
// to expected value.
|
|
|
|
bool CompareAndSwap(uint32_t id, void* ptr, void*& expected);
|
|
|
|
// Reset all thread local data to replacement, and return non-nullptr
|
|
|
|
// data for all existing threads
|
|
|
|
void Scrape(uint32_t id, autovector<void*>* ptrs, void* const replacement);
|
|
|
|
// Update res by applying func on each thread-local value. Holds a lock that
|
|
|
|
// prevents unref handler from running during this call, but clients must
|
|
|
|
// still provide external synchronization since the owning thread can
|
|
|
|
// access the values without internal locking, e.g., via Get() and Reset().
|
|
|
|
void Fold(uint32_t id, FoldFunc func, void* res);
|
|
|
|
|
|
|
|
// Register the UnrefHandler for id
|
|
|
|
void SetHandler(uint32_t id, UnrefHandler handler);
|
|
|
|
|
|
|
|
// protect inst, next_instance_id_, free_instance_ids_, head_,
|
|
|
|
// ThreadData.entries
|
|
|
|
//
|
|
|
|
// Note that here we prefer function static variable instead of the usual
|
|
|
|
// global static variable. The reason is that c++ destruction order of
|
|
|
|
// static variables in the reverse order of their construction order.
|
|
|
|
// However, C++ does not guarantee any construction order when global
|
|
|
|
// static variables are defined in different files, while the function
|
|
|
|
// static variables are initialized when their function are first called.
|
|
|
|
// As a result, the construction order of the function static variables
|
|
|
|
// can be controlled by properly invoke their first function calls in
|
|
|
|
// the right order.
|
|
|
|
//
|
|
|
|
// For instance, the following function contains a function static
|
|
|
|
// variable. We place a dummy function call of this inside
|
|
|
|
// Env::Default() to ensure the construction order of the construction
|
|
|
|
// order.
|
|
|
|
static port::Mutex* Mutex();
|
|
|
|
|
|
|
|
// Returns the member mutex of the current StaticMeta. In general,
|
|
|
|
// Mutex() should be used instead of this one. However, in case where
|
|
|
|
// the static variable inside Instance() goes out of scope, MemberMutex()
|
|
|
|
// should be used. One example is OnThreadExit() function.
|
|
|
|
port::Mutex* MemberMutex() { return &mutex_; }
|
|
|
|
|
|
|
|
private:
|
|
|
|
// Get UnrefHandler for id with acquiring mutex
|
|
|
|
// REQUIRES: mutex locked
|
|
|
|
UnrefHandler GetHandler(uint32_t id);
|
|
|
|
|
|
|
|
// Triggered before a thread terminates
|
|
|
|
static void OnThreadExit(void* ptr);
|
|
|
|
|
|
|
|
// Add current thread's ThreadData to the global chain
|
|
|
|
// REQUIRES: mutex locked
|
|
|
|
void AddThreadData(ThreadData* d);
|
|
|
|
|
|
|
|
// Remove current thread's ThreadData from the global chain
|
|
|
|
// REQUIRES: mutex locked
|
|
|
|
void RemoveThreadData(ThreadData* d);
|
|
|
|
|
|
|
|
static ThreadData* GetThreadLocal();
|
|
|
|
|
|
|
|
uint32_t next_instance_id_;
|
|
|
|
// Used to recycle Ids in case ThreadLocalPtr is instantiated and destroyed
|
|
|
|
// frequently. This also prevents it from blowing up the vector space.
|
|
|
|
autovector<uint32_t> free_instance_ids_;
|
|
|
|
// Chain all thread local structure together. This is necessary since
|
|
|
|
// when one ThreadLocalPtr gets destroyed, we need to loop over each
|
|
|
|
// thread's version of pointer corresponding to that instance and
|
|
|
|
// call UnrefHandler for it.
|
|
|
|
ThreadData head_;
|
|
|
|
|
|
|
|
std::unordered_map<uint32_t, UnrefHandler> handler_map_;
|
|
|
|
|
|
|
|
// The private mutex. Developers should always use Mutex() instead of
|
|
|
|
// using this variable directly.
|
|
|
|
port::Mutex mutex_;
|
|
|
|
// Thread local storage
|
2022-05-19 00:25:19 +02:00
|
|
|
static thread_local ThreadData* tls_;
|
2017-02-02 23:02:41 +01:00
|
|
|
|
|
|
|
// Used to make thread exit trigger possible if !defined(OS_MACOSX).
|
|
|
|
// Otherwise, used to retrieve thread data.
|
|
|
|
pthread_key_t pthread_key_;
|
|
|
|
};
|
|
|
|
|
2022-05-19 00:25:19 +02:00
|
|
|
thread_local ThreadData* ThreadLocalPtr::StaticMeta::tls_ = nullptr;
|
2014-02-26 02:47:37 +01:00
|
|
|
|
2015-07-02 01:13:49 +02:00
|
|
|
// Windows doesn't support a per-thread destructor with its
|
|
|
|
// TLS primitives. So, we build it manually by inserting a
|
|
|
|
// function to be called on each thread's exit.
|
|
|
|
// See http://www.codeproject.com/Articles/8113/Thread-Local-Storage-The-C-Way
|
|
|
|
// and http://www.nynaeve.net/?p=183
|
|
|
|
//
|
2015-07-13 21:11:05 +02:00
|
|
|
// really we do this to have clear conscience since using TLS with thread-pools
|
|
|
|
// is iffy
|
|
|
|
// although OK within a request. But otherwise, threads have no identity in its
|
|
|
|
// modern use.
|
2015-07-02 01:13:49 +02:00
|
|
|
|
|
|
|
// This runs on windows only called from the System Loader
|
|
|
|
#ifdef OS_WIN
|
|
|
|
|
|
|
|
// Windows cleanup routine is invoked from a System Loader with a different
|
2015-07-13 21:11:05 +02:00
|
|
|
// signature so we can not directly hookup the original OnThreadExit which is
|
|
|
|
// private member
|
|
|
|
// so we make StaticMeta class share with the us the address of the function so
|
|
|
|
// we can invoke it.
|
2015-07-02 01:13:49 +02:00
|
|
|
namespace wintlscleanup {
|
|
|
|
|
|
|
|
// This is set to OnThreadExit in StaticMeta singleton constructor
|
2015-07-13 21:11:05 +02:00
|
|
|
UnrefHandler thread_local_inclass_routine = nullptr;
|
2017-10-19 19:48:47 +02:00
|
|
|
pthread_key_t thread_local_key = pthread_key_t (-1);
|
2015-07-02 01:13:49 +02:00
|
|
|
|
|
|
|
// Static callback function to call with each thread termination.
|
|
|
|
void NTAPI WinOnThreadExit(PVOID module, DWORD reason, PVOID reserved) {
|
2015-07-08 01:58:20 +02:00
|
|
|
// We decided to punt on PROCESS_EXIT
|
|
|
|
if (DLL_THREAD_DETACH == reason) {
|
2018-07-20 23:34:07 +02:00
|
|
|
if (thread_local_key != pthread_key_t(-1) &&
|
|
|
|
thread_local_inclass_routine != nullptr) {
|
2018-07-20 00:07:22 +02:00
|
|
|
void* tls = TlsGetValue(thread_local_key);
|
2015-07-13 21:11:05 +02:00
|
|
|
if (tls != nullptr) {
|
2015-07-08 01:58:20 +02:00
|
|
|
thread_local_inclass_routine(tls);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-07-02 01:13:49 +02:00
|
|
|
}
|
|
|
|
|
2015-07-13 21:11:05 +02:00
|
|
|
} // wintlscleanup
|
2015-07-02 01:13:49 +02:00
|
|
|
|
|
|
|
// extern "C" suppresses C++ name mangling so we know the symbol name for the
|
|
|
|
// linker /INCLUDE:symbol pragma above.
|
|
|
|
extern "C" {
|
|
|
|
|
2017-03-31 01:47:19 +02:00
|
|
|
#ifdef _MSC_VER
|
2015-07-02 01:13:49 +02:00
|
|
|
// The linker must not discard thread_callback_on_exit. (We force a reference
|
|
|
|
// to this variable with a linker /include:symbol pragma to ensure that.) If
|
|
|
|
// this variable is discarded, the OnThreadExit function will never be called.
|
2018-10-10 01:56:41 +02:00
|
|
|
#ifndef _X86_
|
2015-07-02 01:13:49 +02:00
|
|
|
|
|
|
|
// .CRT section is merged with .rdata on x64 so it must be constant data.
|
|
|
|
#pragma const_seg(".CRT$XLB")
|
|
|
|
// When defining a const variable, it must have external linkage to be sure the
|
|
|
|
// linker doesn't discard it.
|
|
|
|
extern const PIMAGE_TLS_CALLBACK p_thread_callback_on_exit;
|
2015-07-13 21:11:05 +02:00
|
|
|
const PIMAGE_TLS_CALLBACK p_thread_callback_on_exit =
|
|
|
|
wintlscleanup::WinOnThreadExit;
|
2015-07-02 01:13:49 +02:00
|
|
|
// Reset the default section.
|
|
|
|
#pragma const_seg()
|
|
|
|
|
2017-03-31 01:47:19 +02:00
|
|
|
#pragma comment(linker, "/include:_tls_used")
|
|
|
|
#pragma comment(linker, "/include:p_thread_callback_on_exit")
|
|
|
|
|
2018-10-10 01:56:41 +02:00
|
|
|
#else // _X86_
|
2015-07-02 01:13:49 +02:00
|
|
|
|
|
|
|
#pragma data_seg(".CRT$XLB")
|
|
|
|
PIMAGE_TLS_CALLBACK p_thread_callback_on_exit = wintlscleanup::WinOnThreadExit;
|
|
|
|
// Reset the default section.
|
|
|
|
#pragma data_seg()
|
|
|
|
|
2017-03-31 01:47:19 +02:00
|
|
|
#pragma comment(linker, "/INCLUDE:__tls_used")
|
|
|
|
#pragma comment(linker, "/INCLUDE:_p_thread_callback_on_exit")
|
|
|
|
|
2018-10-10 01:56:41 +02:00
|
|
|
#endif // _X86_
|
2015-07-02 01:13:49 +02:00
|
|
|
|
2017-03-31 01:47:19 +02:00
|
|
|
#else
|
|
|
|
// https://github.com/couchbase/gperftools/blob/master/src/windows/port.cc
|
|
|
|
BOOL WINAPI DllMain(HINSTANCE h, DWORD dwReason, PVOID pv) {
|
|
|
|
if (dwReason == DLL_THREAD_DETACH)
|
|
|
|
wintlscleanup::WinOnThreadExit(h, dwReason, pv);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
#endif
|
2015-07-02 01:13:49 +02:00
|
|
|
} // extern "C"
|
|
|
|
|
2015-07-13 21:11:05 +02:00
|
|
|
#endif // OS_WIN
|
2015-07-02 01:13:49 +02:00
|
|
|
|
Simplify thread-local static initialization
Summary:
The call stack used to look like this during static initialization:
#0 0x00000000008032d1 in rocksdb::ThreadLocalPtr::StaticMeta::StaticMeta() (this=0x7ffff683b300) at util/thread_local.cc:172
#1 0x00000000008030a7 in rocksdb::ThreadLocalPtr::Instance() () at util/thread_local.cc:135
#2 0x000000000080310f in rocksdb::ThreadLocalPtr::StaticMeta::Mutex() () at util/thread_local.cc:141
#3 0x0000000000803103 in rocksdb::ThreadLocalPtr::StaticMeta::InitSingletons() () at util/thread_local.cc:139
#4 0x000000000080305d in rocksdb::ThreadLocalPtr::InitSingletons() () at util/thread_local.cc:106
It involves outer/inner classes and the call stacks goes
outer->inner->outer->inner, which is too difficult to understand. We can avoid
a level of back-and-forth by skipping StaticMeta::InitSingletons(), which
doesn't initialize anything beyond what ThreadLocalPtr::Instance() already
initializes.
Now the call stack looks like this during static initialization:
#0 0x00000000008032c5 in rocksdb::ThreadLocalPtr::StaticMeta::StaticMeta() (this=0x7ffff683b300) at util/thread_local.cc:170
#1 0x00000000008030a7 in rocksdb::ThreadLocalPtr::Instance() () at util/thread_local.cc:135
#2 0x000000000080305d in rocksdb::ThreadLocalPtr::InitSingletons() () at util/thread_local.cc:106
Test Plan:
unit tests
verify StaticMeta::mutex_ is still initialized in DefaultEnv() (StaticMeta::mutex_ is the only variable intended to be initialized via StaticMeta::InitSingletons() which I removed)
#0 0x00000000005cee17 in rocksdb::port::Mutex::Mutex(bool) (this=0x7ffff69500b0, adaptive=false) at port/port_posix.cc:52
#1 0x0000000000769cf8 in rocksdb::ThreadLocalPtr::StaticMeta::StaticMeta() (this=0x7ffff6950000) at util/thread_local.cc:168
#2 0x0000000000769a53 in rocksdb::ThreadLocalPtr::Instance() () at util/thread_local.cc:133
#3 0x0000000000769a09 in rocksdb::ThreadLocalPtr::InitSingletons() () at util/thread_local.cc:105
#4 0x0000000000647d98 in rocksdb::Env::Default() () at util/env_posix.cc:845
Reviewers: lightmark, yhchiang, sdong
Reviewed By: sdong
Subscribers: arahut, IslamAbdelRahman, yiwu, andrewkr, dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D60813
2016-07-28 23:55:22 +02:00
|
|
|
void ThreadLocalPtr::InitSingletons() { ThreadLocalPtr::Instance(); }
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
|
2014-04-23 06:13:34 +02:00
|
|
|
ThreadLocalPtr::StaticMeta* ThreadLocalPtr::Instance() {
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
// Here we prefer function static variable instead of global
|
|
|
|
// static variable as function static variable is initialized
|
|
|
|
// when the function is first call. As a result, we can properly
|
|
|
|
// control their construction order by properly preparing their
|
|
|
|
// first function call.
|
2016-02-11 01:56:01 +01:00
|
|
|
//
|
|
|
|
// Note that here we decide to make "inst" a static pointer w/o deleting
|
|
|
|
// it at the end instead of a static variable. This is to avoid the following
|
2017-03-25 00:58:51 +01:00
|
|
|
// destruction order disaster happens when a child thread using ThreadLocalPtr
|
2016-02-11 01:56:01 +01:00
|
|
|
// dies AFTER the main thread dies: When a child thread happens to use
|
|
|
|
// ThreadLocalPtr, it will try to delete its thread-local data on its
|
|
|
|
// OnThreadExit when the child thread dies. However, OnThreadExit depends
|
|
|
|
// on the following variable. As a result, if the main thread dies before any
|
|
|
|
// child thread happen to use ThreadLocalPtr dies, then the destruction of
|
|
|
|
// the following variable will go first, then OnThreadExit, therefore causing
|
|
|
|
// invalid access.
|
|
|
|
//
|
2022-05-19 00:25:19 +02:00
|
|
|
// The above problem can be solved by using thread_local to store tls_.
|
|
|
|
// thread_local supports dynamic construction and destruction of
|
2016-02-11 01:56:01 +01:00
|
|
|
// non-primitive typed variables. As a result, we can guarantee the
|
2016-10-29 20:54:27 +02:00
|
|
|
// destruction order even when the main thread dies before any child threads.
|
2016-02-11 01:56:01 +01:00
|
|
|
static ThreadLocalPtr::StaticMeta* inst = new ThreadLocalPtr::StaticMeta();
|
|
|
|
return inst;
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
2016-02-11 01:56:01 +01:00
|
|
|
port::Mutex* ThreadLocalPtr::StaticMeta::Mutex() { return &Instance()->mutex_; }
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
|
2014-02-26 02:47:37 +01:00
|
|
|
void ThreadLocalPtr::StaticMeta::OnThreadExit(void* ptr) {
|
|
|
|
auto* tls = static_cast<ThreadData*>(ptr);
|
|
|
|
assert(tls != nullptr);
|
|
|
|
|
2016-02-11 01:56:01 +01:00
|
|
|
// Use the cached StaticMeta::Instance() instead of directly calling
|
|
|
|
// the variable inside StaticMeta::Instance() might already go out of
|
|
|
|
// scope here in case this OnThreadExit is called after the main thread
|
|
|
|
// dies.
|
|
|
|
auto* inst = tls->inst;
|
2014-02-26 02:47:37 +01:00
|
|
|
pthread_setspecific(inst->pthread_key_, nullptr);
|
|
|
|
|
2016-02-11 01:56:01 +01:00
|
|
|
MutexLock l(inst->MemberMutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
inst->RemoveThreadData(tls);
|
|
|
|
// Unref stored pointers of current thread from all instances
|
|
|
|
uint32_t id = 0;
|
|
|
|
for (auto& e : tls->entries) {
|
2015-01-27 05:23:15 +01:00
|
|
|
void* raw = e.ptr.load();
|
2014-02-26 02:47:37 +01:00
|
|
|
if (raw != nullptr) {
|
|
|
|
auto unref = inst->GetHandler(id);
|
|
|
|
if (unref != nullptr) {
|
|
|
|
unref(raw);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
++id;
|
|
|
|
}
|
|
|
|
// Delete thread local structure no matter if it is Mac platform
|
|
|
|
delete tls;
|
|
|
|
}
|
|
|
|
|
2017-11-03 22:32:00 +01:00
|
|
|
ThreadLocalPtr::StaticMeta::StaticMeta()
|
|
|
|
: next_instance_id_(0),
|
|
|
|
head_(this),
|
|
|
|
pthread_key_(0) {
|
2014-02-26 02:47:37 +01:00
|
|
|
if (pthread_key_create(&pthread_key_, &OnThreadExit) != 0) {
|
2014-12-04 22:35:31 +01:00
|
|
|
abort();
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
2015-08-06 00:45:21 +02:00
|
|
|
|
|
|
|
// OnThreadExit is not getting called on the main thread.
|
|
|
|
// Call through the static destructor mechanism to avoid memory leak.
|
2015-08-07 19:47:05 +02:00
|
|
|
//
|
|
|
|
// Caveats: ~A() will be invoked _after_ ~StaticMeta for the global
|
|
|
|
// singleton (destructors are invoked in reverse order of constructor
|
|
|
|
// _completion_); the latter must not mutate internal members. This
|
|
|
|
// cleanup mechanism inherently relies on use-after-release of the
|
|
|
|
// StaticMeta, and is brittle with respect to compiler-specific handling
|
|
|
|
// of memory backing destructed statically-scoped objects. Perhaps
|
|
|
|
// registering with atexit(3) would be more robust.
|
|
|
|
//
|
2015-08-11 22:30:49 +02:00
|
|
|
// This is not required on Windows.
|
|
|
|
#if !defined(OS_WIN)
|
2015-08-06 00:45:21 +02:00
|
|
|
static struct A {
|
|
|
|
~A() {
|
|
|
|
if (tls_) {
|
|
|
|
OnThreadExit(tls_);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} a;
|
2015-08-11 22:30:49 +02:00
|
|
|
#endif // !defined(OS_WIN)
|
2015-08-06 00:45:21 +02:00
|
|
|
|
2014-02-26 02:47:37 +01:00
|
|
|
head_.next = &head_;
|
|
|
|
head_.prev = &head_;
|
2015-07-02 01:13:49 +02:00
|
|
|
|
|
|
|
#ifdef OS_WIN
|
2015-07-13 21:11:05 +02:00
|
|
|
// Share with Windows its cleanup routine and the key
|
2015-07-02 01:13:49 +02:00
|
|
|
wintlscleanup::thread_local_inclass_routine = OnThreadExit;
|
|
|
|
wintlscleanup::thread_local_key = pthread_key_;
|
|
|
|
#endif
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
2017-02-02 23:02:41 +01:00
|
|
|
void ThreadLocalPtr::StaticMeta::AddThreadData(ThreadData* d) {
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
Mutex()->AssertHeld();
|
2014-02-26 02:47:37 +01:00
|
|
|
d->next = &head_;
|
|
|
|
d->prev = head_.prev;
|
|
|
|
head_.prev->next = d;
|
|
|
|
head_.prev = d;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadLocalPtr::StaticMeta::RemoveThreadData(
|
2017-02-02 23:02:41 +01:00
|
|
|
ThreadData* d) {
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
Mutex()->AssertHeld();
|
2014-02-26 02:47:37 +01:00
|
|
|
d->next->prev = d->prev;
|
|
|
|
d->prev->next = d->next;
|
|
|
|
d->next = d->prev = d;
|
|
|
|
}
|
|
|
|
|
2017-02-02 23:02:41 +01:00
|
|
|
ThreadData* ThreadLocalPtr::StaticMeta::GetThreadLocal() {
|
2014-02-26 02:47:37 +01:00
|
|
|
if (UNLIKELY(tls_ == nullptr)) {
|
|
|
|
auto* inst = Instance();
|
2016-02-11 01:56:01 +01:00
|
|
|
tls_ = new ThreadData(inst);
|
2014-02-26 02:47:37 +01:00
|
|
|
{
|
|
|
|
// Register it in the global chain, needs to be done before thread exit
|
|
|
|
// handler registration
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
inst->AddThreadData(tls_);
|
|
|
|
}
|
|
|
|
// Even it is not OS_MACOSX, need to register value for pthread_key_ so that
|
|
|
|
// its exit handler will be triggered.
|
|
|
|
if (pthread_setspecific(inst->pthread_key_, tls_) != 0) {
|
|
|
|
{
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
inst->RemoveThreadData(tls_);
|
|
|
|
}
|
|
|
|
delete tls_;
|
2014-12-04 22:35:31 +01:00
|
|
|
abort();
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return tls_;
|
|
|
|
}
|
|
|
|
|
|
|
|
void* ThreadLocalPtr::StaticMeta::Get(uint32_t id) const {
|
|
|
|
auto* tls = GetThreadLocal();
|
|
|
|
if (UNLIKELY(id >= tls->entries.size())) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
2015-01-27 05:23:15 +01:00
|
|
|
return tls->entries[id].ptr.load(std::memory_order_acquire);
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadLocalPtr::StaticMeta::Reset(uint32_t id, void* ptr) {
|
|
|
|
auto* tls = GetThreadLocal();
|
|
|
|
if (UNLIKELY(id >= tls->entries.size())) {
|
|
|
|
// Need mutex to protect entries access within ReclaimId
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
tls->entries.resize(id + 1);
|
|
|
|
}
|
2015-01-27 05:23:15 +01:00
|
|
|
tls->entries[id].ptr.store(ptr, std::memory_order_release);
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void* ThreadLocalPtr::StaticMeta::Swap(uint32_t id, void* ptr) {
|
|
|
|
auto* tls = GetThreadLocal();
|
|
|
|
if (UNLIKELY(id >= tls->entries.size())) {
|
|
|
|
// Need mutex to protect entries access within ReclaimId
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
tls->entries.resize(id + 1);
|
|
|
|
}
|
2015-01-27 05:23:15 +01:00
|
|
|
return tls->entries[id].ptr.exchange(ptr, std::memory_order_acquire);
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
2014-03-07 23:43:22 +01:00
|
|
|
bool ThreadLocalPtr::StaticMeta::CompareAndSwap(uint32_t id, void* ptr,
|
|
|
|
void*& expected) {
|
|
|
|
auto* tls = GetThreadLocal();
|
|
|
|
if (UNLIKELY(id >= tls->entries.size())) {
|
|
|
|
// Need mutex to protect entries access within ReclaimId
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-03-07 23:43:22 +01:00
|
|
|
tls->entries.resize(id + 1);
|
|
|
|
}
|
2015-01-27 05:23:15 +01:00
|
|
|
return tls->entries[id].ptr.compare_exchange_strong(
|
|
|
|
expected, ptr, std::memory_order_release, std::memory_order_relaxed);
|
2014-03-07 23:43:22 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadLocalPtr::StaticMeta::Scrape(uint32_t id, autovector<void*>* ptrs,
|
|
|
|
void* const replacement) {
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
for (ThreadData* t = head_.next; t != &head_; t = t->next) {
|
|
|
|
if (id < t->entries.size()) {
|
|
|
|
void* ptr =
|
2015-01-27 05:23:15 +01:00
|
|
|
t->entries[id].ptr.exchange(replacement, std::memory_order_acquire);
|
2014-02-26 02:47:37 +01:00
|
|
|
if (ptr != nullptr) {
|
|
|
|
ptrs->push_back(ptr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-23 00:37:39 +02:00
|
|
|
void ThreadLocalPtr::StaticMeta::Fold(uint32_t id, FoldFunc func, void* res) {
|
|
|
|
MutexLock l(Mutex());
|
|
|
|
for (ThreadData* t = head_.next; t != &head_; t = t->next) {
|
|
|
|
if (id < t->entries.size()) {
|
|
|
|
void* ptr = t->entries[id].ptr.load();
|
|
|
|
if (ptr != nullptr) {
|
|
|
|
func(ptr, res);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-02 23:02:41 +01:00
|
|
|
uint32_t ThreadLocalPtr::TEST_PeekId() {
|
|
|
|
return Instance()->PeekId();
|
|
|
|
}
|
|
|
|
|
2014-02-26 02:47:37 +01:00
|
|
|
void ThreadLocalPtr::StaticMeta::SetHandler(uint32_t id, UnrefHandler handler) {
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
handler_map_[id] = handler;
|
|
|
|
}
|
|
|
|
|
|
|
|
UnrefHandler ThreadLocalPtr::StaticMeta::GetHandler(uint32_t id) {
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
Mutex()->AssertHeld();
|
2014-02-26 02:47:37 +01:00
|
|
|
auto iter = handler_map_.find(id);
|
|
|
|
if (iter == handler_map_.end()) {
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
return iter->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t ThreadLocalPtr::StaticMeta::GetId() {
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
if (free_instance_ids_.empty()) {
|
|
|
|
return next_instance_id_++;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t id = free_instance_ids_.back();
|
|
|
|
free_instance_ids_.pop_back();
|
|
|
|
return id;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t ThreadLocalPtr::StaticMeta::PeekId() const {
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
if (!free_instance_ids_.empty()) {
|
|
|
|
return free_instance_ids_.back();
|
|
|
|
}
|
|
|
|
return next_instance_id_;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadLocalPtr::StaticMeta::ReclaimId(uint32_t id) {
|
|
|
|
// This id is not used, go through all thread local data and release
|
|
|
|
// corresponding value
|
Ensure the destruction order of PosixEnv and ThreadLocalPtr
Summary:
By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
via static initializer. Destructor terminates objects in reverse order, so terminating PosixEnv
(calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
This patch fix this issue by ensuring the destruction order by moving the global static singletons
to function static singletons. Since function static singletons are initialized when the function is first
called, this property allows us invoke to enforce the construction of the static PosixEnv and the
singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
right before we initialize the static PosixEnv.
Test Plan: Verified in the MyRocks.
Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
Reviewed By: anthony
Subscribers: dhruba, leveldb
Differential Revision: https://reviews.facebook.net/D51789
2015-12-11 09:21:58 +01:00
|
|
|
MutexLock l(Mutex());
|
2014-02-26 02:47:37 +01:00
|
|
|
auto unref = GetHandler(id);
|
|
|
|
for (ThreadData* t = head_.next; t != &head_; t = t->next) {
|
|
|
|
if (id < t->entries.size()) {
|
2015-01-27 05:23:15 +01:00
|
|
|
void* ptr = t->entries[id].ptr.exchange(nullptr);
|
2014-02-26 02:47:37 +01:00
|
|
|
if (ptr != nullptr && unref != nullptr) {
|
|
|
|
unref(ptr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
handler_map_[id] = nullptr;
|
|
|
|
free_instance_ids_.push_back(id);
|
|
|
|
}
|
|
|
|
|
|
|
|
ThreadLocalPtr::ThreadLocalPtr(UnrefHandler handler)
|
2014-04-23 06:13:34 +02:00
|
|
|
: id_(Instance()->GetId()) {
|
2014-02-26 02:47:37 +01:00
|
|
|
if (handler != nullptr) {
|
2014-04-23 06:13:34 +02:00
|
|
|
Instance()->SetHandler(id_, handler);
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ThreadLocalPtr::~ThreadLocalPtr() {
|
2014-04-23 06:13:34 +02:00
|
|
|
Instance()->ReclaimId(id_);
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void* ThreadLocalPtr::Get() const {
|
2014-04-23 06:13:34 +02:00
|
|
|
return Instance()->Get(id_);
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadLocalPtr::Reset(void* ptr) {
|
2014-04-23 06:13:34 +02:00
|
|
|
Instance()->Reset(id_, ptr);
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void* ThreadLocalPtr::Swap(void* ptr) {
|
2014-04-23 06:13:34 +02:00
|
|
|
return Instance()->Swap(id_, ptr);
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
2014-03-07 23:43:22 +01:00
|
|
|
bool ThreadLocalPtr::CompareAndSwap(void* ptr, void*& expected) {
|
2014-04-23 06:13:34 +02:00
|
|
|
return Instance()->CompareAndSwap(id_, ptr, expected);
|
2014-03-07 23:43:22 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void ThreadLocalPtr::Scrape(autovector<void*>* ptrs, void* const replacement) {
|
2014-04-23 06:13:34 +02:00
|
|
|
Instance()->Scrape(id_, ptrs, replacement);
|
2014-02-26 02:47:37 +01:00
|
|
|
}
|
|
|
|
|
2016-08-23 00:37:39 +02:00
|
|
|
void ThreadLocalPtr::Fold(FoldFunc func, void* res) {
|
|
|
|
Instance()->Fold(id_, func, res);
|
|
|
|
}
|
|
|
|
|
2020-02-20 21:07:53 +01:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|