2016-02-09 23:12:00 +00:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
2014-02-26 01:47:37 +00:00
|
|
|
// This source code is licensed under the BSD-style license found in the
|
|
|
|
// LICENSE file in the root directory of this source tree. An additional grant
|
|
|
|
// of patent rights can be found in the PATENTS file in the same directory.
|
|
|
|
//
|
|
|
|
// 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.
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include <atomic>
|
|
|
|
#include <memory>
|
|
|
|
#include <unordered_map>
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
#include "util/autovector.h"
|
2015-07-01 23:13:49 +00:00
|
|
|
#include "port/port.h"
|
|
|
|
|
2015-08-11 20:30:49 +00:00
|
|
|
#ifndef ROCKSDB_SUPPORT_THREAD_LOCAL
|
|
|
|
#define ROCKSDB_SUPPORT_THREAD_LOCAL \
|
|
|
|
!defined(OS_WIN) && !defined(OS_MACOSX) && !defined(IOS_CROSS_COMPILE)
|
|
|
|
#endif
|
|
|
|
|
2014-02-26 01:47:37 +00:00
|
|
|
namespace rocksdb {
|
|
|
|
|
|
|
|
// Cleanup function that will be called for a stored thread local
|
|
|
|
// pointer (if not NULL) when one of the following happens:
|
|
|
|
// (1) a thread terminates
|
|
|
|
// (2) a ThreadLocalPtr is destroyed
|
|
|
|
typedef void (*UnrefHandler)(void* ptr);
|
|
|
|
|
2014-10-22 00:28:31 +00:00
|
|
|
// ThreadLocalPtr stores only values of pointer type. Different from
|
|
|
|
// the usual thread-local-storage, ThreadLocalPtr has the ability to
|
|
|
|
// distinguish data coming from different threads and different
|
|
|
|
// ThreadLocalPtr instances. For example, if a regular thread_local
|
|
|
|
// variable A is declared in DBImpl, two DBImpl objects would share
|
|
|
|
// the same A. However, a ThreadLocalPtr that is defined under the
|
|
|
|
// scope of DBImpl can avoid such confliction. As a result, its memory
|
|
|
|
// usage would be O(# of threads * # of ThreadLocalPtr instances).
|
2014-02-26 01:47:37 +00:00
|
|
|
class ThreadLocalPtr {
|
|
|
|
public:
|
|
|
|
explicit ThreadLocalPtr(UnrefHandler handler = nullptr);
|
|
|
|
|
|
|
|
~ThreadLocalPtr();
|
|
|
|
|
|
|
|
// Return the current pointer stored in thread local
|
|
|
|
void* Get() const;
|
|
|
|
|
|
|
|
// Set a new pointer value to the thread local storage.
|
|
|
|
void Reset(void* ptr);
|
|
|
|
|
|
|
|
// Atomically swap the supplied ptr and return the previous value
|
|
|
|
void* Swap(void* ptr);
|
|
|
|
|
2014-03-07 22:43:22 +00:00
|
|
|
// Atomically compare the stored value with expected. Set the new
|
2015-12-10 16:54:48 +00:00
|
|
|
// pointer value to thread local only if the comparison is true.
|
2014-03-07 22:43:22 +00:00
|
|
|
// Otherwise, expected returns the stored value.
|
|
|
|
// Return true on success, false on failure
|
|
|
|
bool CompareAndSwap(void* ptr, void*& expected);
|
|
|
|
|
|
|
|
// Reset all thread local data to replacement, and return non-nullptr
|
|
|
|
// data for all existing threads
|
|
|
|
void Scrape(autovector<void*>* ptrs, void* const replacement);
|
2014-02-26 01:47:37 +00:00
|
|
|
|
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 08:21:58 +00:00
|
|
|
// Initialize the static singletons of the ThreadLocalPtr.
|
|
|
|
//
|
|
|
|
// If this function is not called, then the singletons will be
|
|
|
|
// automatically initialized when they are used.
|
|
|
|
//
|
|
|
|
// Calling this function twice or after the singletons have been
|
|
|
|
// initialized will be no-op.
|
|
|
|
static void InitSingletons();
|
|
|
|
|
2014-02-26 01:47:37 +00:00
|
|
|
protected:
|
|
|
|
struct Entry {
|
|
|
|
Entry() : ptr(nullptr) {}
|
|
|
|
Entry(const Entry& e) : ptr(e.ptr.load(std::memory_order_relaxed)) {}
|
|
|
|
std::atomic<void*> ptr;
|
|
|
|
};
|
|
|
|
|
|
|
|
// 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:
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | | instance 1 | instance 2 | instnace 3 |
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | thread 1 | void* | void* | void* | <- ThreadData
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | thread 2 | void* | void* | void* | <- ThreadData
|
|
|
|
// ---------------------------------------------------
|
|
|
|
// | thread 3 | void* | void* | void* | <- ThreadData
|
|
|
|
// ---------------------------------------------------
|
|
|
|
struct ThreadData {
|
|
|
|
ThreadData() : entries() {}
|
|
|
|
std::vector<Entry> entries;
|
|
|
|
ThreadData* next;
|
|
|
|
ThreadData* prev;
|
|
|
|
};
|
|
|
|
|
|
|
|
class StaticMeta {
|
|
|
|
public:
|
2014-04-23 04:13:34 +00:00
|
|
|
StaticMeta();
|
2014-02-26 01:47:37 +00:00
|
|
|
|
|
|
|
// Return the next available Id
|
|
|
|
uint32_t GetId();
|
2015-12-10 16:54:48 +00:00
|
|
|
// Return the next available Id without claiming it
|
2014-02-26 01:47:37 +00:00
|
|
|
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.
|
|
|
|
// It triggers UnrefHanlder if the id has existing pointer value.
|
|
|
|
void Reset(uint32_t id, void* ptr);
|
|
|
|
// Atomically swap the supplied ptr and return the previous value
|
|
|
|
void* Swap(uint32_t id, void* ptr);
|
2014-03-07 22:43:22 +00:00
|
|
|
// 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);
|
2014-02-26 01:47:37 +00:00
|
|
|
|
|
|
|
// Register the UnrefHandler for id
|
|
|
|
void 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 08:21:58 +00:00
|
|
|
// Initialize all the singletons associated with StaticMeta.
|
|
|
|
//
|
|
|
|
// If this function is not called, then the singletons will be
|
|
|
|
// automatically initialized when they are used.
|
|
|
|
//
|
|
|
|
// Calling this function twice or after the singletons have been
|
|
|
|
// initialized will be no-op.
|
|
|
|
static void InitSingletons();
|
|
|
|
|
2014-02-26 01:47:37 +00:00
|
|
|
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_;
|
|
|
|
|
|
|
|
// protect inst, next_instance_id_, free_instance_ids_, head_,
|
|
|
|
// ThreadData.entries
|
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 08:21:58 +00:00
|
|
|
//
|
|
|
|
// 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();
|
2015-08-11 20:30:49 +00:00
|
|
|
#if ROCKSDB_SUPPORT_THREAD_LOCAL
|
2014-02-26 01:47:37 +00:00
|
|
|
// Thread local storage
|
|
|
|
static __thread ThreadData* tls_;
|
|
|
|
#endif
|
2015-07-01 23:13:49 +00:00
|
|
|
|
2014-02-26 01:47:37 +00:00
|
|
|
// Used to make thread exit trigger possible if !defined(OS_MACOSX).
|
|
|
|
// Otherwise, used to retrieve thread data.
|
|
|
|
pthread_key_t pthread_key_;
|
|
|
|
};
|
|
|
|
|
2014-04-23 04:13:34 +00:00
|
|
|
static StaticMeta* Instance();
|
|
|
|
|
2014-02-26 01:47:37 +00:00
|
|
|
const uint32_t id_;
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace rocksdb
|