rocksdb/utilities/transactions/transaction_db_mutex_impl.cc

134 lines
3.6 KiB
C++
Raw Normal View History

// 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).
#include "utilities/transactions/transaction_db_mutex_impl.h"
#include <chrono>
#include <condition_variable>
#include <functional>
#include <mutex>
#include "rocksdb/utilities/transaction_db_mutex.h"
namespace ROCKSDB_NAMESPACE {
class TransactionDBMutexImpl : public TransactionDBMutex {
public:
TransactionDBMutexImpl() {}
~TransactionDBMutexImpl() override {}
Status Lock() override;
Status TryLockFor(int64_t timeout_time) override;
void UnLock() override { mutex_.unlock(); }
friend class TransactionDBCondVarImpl;
private:
std::mutex mutex_;
};
class TransactionDBCondVarImpl : public TransactionDBCondVar {
public:
TransactionDBCondVarImpl() {}
~TransactionDBCondVarImpl() override {}
Status Wait(std::shared_ptr<TransactionDBMutex> mutex) override;
Status WaitFor(std::shared_ptr<TransactionDBMutex> mutex,
int64_t timeout_time) override;
void Notify() override { cv_.notify_one(); }
void NotifyAll() override { cv_.notify_all(); }
private:
std::condition_variable cv_;
};
std::shared_ptr<TransactionDBMutex>
TransactionDBMutexFactoryImpl::AllocateMutex() {
return std::shared_ptr<TransactionDBMutex>(new TransactionDBMutexImpl());
}
std::shared_ptr<TransactionDBCondVar>
TransactionDBMutexFactoryImpl::AllocateCondVar() {
return std::shared_ptr<TransactionDBCondVar>(new TransactionDBCondVarImpl());
}
Status TransactionDBMutexImpl::Lock() {
mutex_.lock();
return Status::OK();
}
Status TransactionDBMutexImpl::TryLockFor(int64_t timeout_time) {
bool locked = true;
if (timeout_time == 0) {
locked = mutex_.try_lock();
} else {
// Previously, this code used a std::timed_mutex. However, this was changed
// due to known bugs in gcc versions < 4.9.
// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
//
// Since this mutex isn't held for long and only a single mutex is ever
// held at a time, it is reasonable to ignore the lock timeout_time here
// and only check it when waiting on the condition_variable.
mutex_.lock();
}
if (!locked) {
// timeout acquiring mutex
return Status::TimedOut(Status::SubCode::kMutexTimeout);
}
return Status::OK();
}
Status TransactionDBCondVarImpl::Wait(
std::shared_ptr<TransactionDBMutex> mutex) {
Prefer static_cast in place of most reinterpret_cast (#12308) Summary: The following are risks associated with pointer-to-pointer reinterpret_cast: * Can produce the "wrong result" (crash or memory corruption). IIRC, in theory this can happen for any up-cast or down-cast for a non-standard-layout type, though in practice would only happen for multiple inheritance cases (where the base class pointer might be "inside" the derived object). We don't use multiple inheritance a lot, but we do. * Can mask useful compiler errors upon code change, including converting between unrelated pointer types that you are expecting to be related, and converting between pointer and scalar types unintentionally. I can only think of some obscure cases where static_cast could be troublesome when it compiles as a replacement: * Going through `void*` could plausibly cause unnecessary or broken pointer arithmetic. Suppose we have `struct Derived: public Base1, public Base2`. If we have `Derived*` -> `void*` -> `Base2*` -> `Derived*` through reinterpret casts, this could plausibly work (though technical UB) assuming the `Base2*` is not dereferenced. Changing to static cast could introduce breaking pointer arithmetic. * Unnecessary (but safe) pointer arithmetic could arise in a case like `Derived*` -> `Base2*` -> `Derived*` where before the Base2 pointer might not have been dereferenced. This could potentially affect performance. With some light scripting, I tried replacing pointer-to-pointer reinterpret_casts with static_cast and kept the cases that still compile. Most occurrences of reinterpret_cast have successfully been changed (except for java/ and third-party/). 294 changed, 257 remain. A couple of related interventions included here: * Previously Cache::Handle was not actually derived from in the implementations and just used as a `void*` stand-in with reinterpret_cast. Now there is a relationship to allow static_cast. In theory, this could introduce pointer arithmetic (as described above) but is unlikely without multiple inheritance AND non-empty Cache::Handle. * Remove some unnecessary casts to void* as this is allowed to be implicit (for better or worse). Most of the remaining reinterpret_casts are for converting to/from raw bytes of objects. We could consider better idioms for these patterns in follow-up work. I wish there were a way to implement a template variant of static_cast that would only compile if no pointer arithmetic is generated, but best I can tell, this is not possible. AFAIK the best you could do is a dynamic check that the void* conversion after the static cast is unchanged. Pull Request resolved: https://github.com/facebook/rocksdb/pull/12308 Test Plan: existing tests, CI Reviewed By: ltamasi Differential Revision: D53204947 Pulled By: pdillinger fbshipit-source-id: 9de23e618263b0d5b9820f4e15966876888a16e2
2024-02-07 18:44:11 +00:00
auto mutex_impl = static_cast<TransactionDBMutexImpl*>(mutex.get());
std::unique_lock<std::mutex> lock(mutex_impl->mutex_, std::adopt_lock);
cv_.wait(lock);
// Make sure unique_lock doesn't unlock mutex when it destructs
lock.release();
return Status::OK();
}
Status TransactionDBCondVarImpl::WaitFor(
std::shared_ptr<TransactionDBMutex> mutex, int64_t timeout_time) {
Status s;
Prefer static_cast in place of most reinterpret_cast (#12308) Summary: The following are risks associated with pointer-to-pointer reinterpret_cast: * Can produce the "wrong result" (crash or memory corruption). IIRC, in theory this can happen for any up-cast or down-cast for a non-standard-layout type, though in practice would only happen for multiple inheritance cases (where the base class pointer might be "inside" the derived object). We don't use multiple inheritance a lot, but we do. * Can mask useful compiler errors upon code change, including converting between unrelated pointer types that you are expecting to be related, and converting between pointer and scalar types unintentionally. I can only think of some obscure cases where static_cast could be troublesome when it compiles as a replacement: * Going through `void*` could plausibly cause unnecessary or broken pointer arithmetic. Suppose we have `struct Derived: public Base1, public Base2`. If we have `Derived*` -> `void*` -> `Base2*` -> `Derived*` through reinterpret casts, this could plausibly work (though technical UB) assuming the `Base2*` is not dereferenced. Changing to static cast could introduce breaking pointer arithmetic. * Unnecessary (but safe) pointer arithmetic could arise in a case like `Derived*` -> `Base2*` -> `Derived*` where before the Base2 pointer might not have been dereferenced. This could potentially affect performance. With some light scripting, I tried replacing pointer-to-pointer reinterpret_casts with static_cast and kept the cases that still compile. Most occurrences of reinterpret_cast have successfully been changed (except for java/ and third-party/). 294 changed, 257 remain. A couple of related interventions included here: * Previously Cache::Handle was not actually derived from in the implementations and just used as a `void*` stand-in with reinterpret_cast. Now there is a relationship to allow static_cast. In theory, this could introduce pointer arithmetic (as described above) but is unlikely without multiple inheritance AND non-empty Cache::Handle. * Remove some unnecessary casts to void* as this is allowed to be implicit (for better or worse). Most of the remaining reinterpret_casts are for converting to/from raw bytes of objects. We could consider better idioms for these patterns in follow-up work. I wish there were a way to implement a template variant of static_cast that would only compile if no pointer arithmetic is generated, but best I can tell, this is not possible. AFAIK the best you could do is a dynamic check that the void* conversion after the static cast is unchanged. Pull Request resolved: https://github.com/facebook/rocksdb/pull/12308 Test Plan: existing tests, CI Reviewed By: ltamasi Differential Revision: D53204947 Pulled By: pdillinger fbshipit-source-id: 9de23e618263b0d5b9820f4e15966876888a16e2
2024-02-07 18:44:11 +00:00
auto mutex_impl = static_cast<TransactionDBMutexImpl*>(mutex.get());
std::unique_lock<std::mutex> lock(mutex_impl->mutex_, std::adopt_lock);
if (timeout_time < 0) {
// If timeout is negative, do not use a timeout
cv_.wait(lock);
} else {
auto duration = std::chrono::microseconds(timeout_time);
auto cv_status = cv_.wait_for(lock, duration);
// Check if the wait stopped due to timing out.
if (cv_status == std::cv_status::timeout) {
s = Status::TimedOut(Status::SubCode::kMutexTimeout);
}
}
// Make sure unique_lock doesn't unlock mutex when it destructs
lock.release();
// CV was signaled, or we spuriously woke up (but didn't time out)
return s;
}
} // namespace ROCKSDB_NAMESPACE