|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
|
|
|
// 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).
|
|
|
|
//
|
|
|
|
// 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 <functional>
|
|
|
|
#include <memory>
|
|
|
|
#include <unordered_map>
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
#include "port/port.h"
|
|
|
|
#include "util/autovector.h"
|
|
|
|
|
|
|
|
namespace ROCKSDB_NAMESPACE {
|
|
|
|
|
|
|
|
// 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
|
Fix deadlock in ColumnFamilyData::InstallSuperVersion()
Summary:
Deadlock: a memtable flush holds DB::mutex_ and calls ThreadLocalPtr::Scrape(), which locks ThreadLocalPtr mutex; meanwhile, a thread exit handler locks ThreadLocalPtr mutex and calls SuperVersionUnrefHandle, which tries to lock DB::mutex_.
This deadlock is hit all the time on our workload. It blocks our release.
In general, the problem is that ThreadLocalPtr takes an arbitrary callback and calls it while holding a lock on a global mutex. The same global mutex is (at least in some cases) locked by almost all ThreadLocalPtr methods, on any instance of ThreadLocalPtr. So, there'll be a deadlock if the callback tries to do anything to any instance of ThreadLocalPtr, or waits for another thread to do so.
So, probably the only safe way to use ThreadLocalPtr callbacks is to do only do simple and lock-free things in them.
This PR fixes the deadlock by making sure that local_sv_ never holds the last reference to a SuperVersion, and therefore SuperVersionUnrefHandle never has to do any nontrivial cleanup.
I also searched for other uses of ThreadLocalPtr to see if they may have similar bugs. There's only one other use, in transaction_lock_mgr.cc, and it looks fine.
Closes https://github.com/facebook/rocksdb/pull/3510
Reviewed By: sagar0
Differential Revision: D7005346
Pulled By: al13n321
fbshipit-source-id: 37575591b84f07a891d6659e87e784660fde815f
7 years ago
|
|
|
//
|
|
|
|
// Warning: this function is called while holding a global mutex. The same mutex
|
|
|
|
// is used (at least in some cases) by most methods of ThreadLocalPtr, and it's
|
|
|
|
// shared across all instances of ThreadLocalPtr. Thereforere extra care
|
|
|
|
// is needed to avoid deadlocks. In particular, the handler shouldn't lock any
|
|
|
|
// mutexes and shouldn't call any methods of any ThreadLocalPtr instances,
|
|
|
|
// unless you know what you're doing.
|
|
|
|
using UnrefHandler = void (*)(void* ptr);
|
|
|
|
|
|
|
|
// 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).
|
|
|
|
class ThreadLocalPtr {
|
|
|
|
public:
|
|
|
|
explicit ThreadLocalPtr(UnrefHandler handler = nullptr);
|
|
|
|
|
|
|
|
ThreadLocalPtr(const ThreadLocalPtr&) = delete;
|
|
|
|
ThreadLocalPtr& operator=(const ThreadLocalPtr&) = delete;
|
|
|
|
|
|
|
|
~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);
|
|
|
|
|
|
|
|
// Atomically compare the stored value with expected. Set the new
|
|
|
|
// pointer value to thread local only if the comparison is true.
|
|
|
|
// 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);
|
|
|
|
|
|
|
|
using FoldFunc = std::function<void(void*, void*)>;
|
|
|
|
// 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(FoldFunc func, void* res);
|
|
|
|
|
|
|
|
// Add here for testing
|
|
|
|
// Return the next available Id without claiming it
|
|
|
|
static uint32_t TEST_PeekId();
|
|
|
|
|
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
9 years ago
|
|
|
// 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();
|
|
|
|
|
|
|
|
class StaticMeta;
|
|
|
|
|
|
|
|
private:
|
|
|
|
static StaticMeta* Instance();
|
|
|
|
|
|
|
|
const uint32_t id_;
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace ROCKSDB_NAMESPACE
|