2016-02-09 23:12:00 +00:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
2017-07-15 23:03:42 +00: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).
|
2015-09-08 19:36:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
#include "utilities/transactions/transaction_db_mutex_impl.h"
|
|
|
|
|
|
|
|
#include <chrono>
|
|
|
|
#include <condition_variable>
|
|
|
|
#include <functional>
|
|
|
|
#include <mutex>
|
|
|
|
|
|
|
|
#include "rocksdb/utilities/transaction_db_mutex.h"
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2015-09-08 19:36:48 +00:00
|
|
|
|
|
|
|
class TransactionDBMutexImpl : public TransactionDBMutex {
|
|
|
|
public:
|
2016-02-10 02:24:41 +00:00
|
|
|
TransactionDBMutexImpl() {}
|
2019-02-14 21:52:47 +00:00
|
|
|
~TransactionDBMutexImpl() override {}
|
2015-09-08 19:36:48 +00:00
|
|
|
|
|
|
|
Status Lock() override;
|
|
|
|
|
|
|
|
Status TryLockFor(int64_t timeout_time) override;
|
|
|
|
|
2016-02-10 02:24:41 +00:00
|
|
|
void UnLock() override { mutex_.unlock(); }
|
2015-09-08 19:36:48 +00:00
|
|
|
|
|
|
|
friend class TransactionDBCondVarImpl;
|
|
|
|
|
|
|
|
private:
|
2016-02-10 02:24:41 +00:00
|
|
|
std::mutex mutex_;
|
2015-09-08 19:36:48 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
class TransactionDBCondVarImpl : public TransactionDBCondVar {
|
|
|
|
public:
|
|
|
|
TransactionDBCondVarImpl() {}
|
2019-02-14 21:52:47 +00:00
|
|
|
~TransactionDBCondVarImpl() override {}
|
2015-09-08 19:36:48 +00:00
|
|
|
|
|
|
|
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:
|
2015-12-19 01:08:47 +00:00
|
|
|
std::condition_variable cv_;
|
2015-09-08 19:36:48 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
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() {
|
2016-02-10 02:24:41 +00:00
|
|
|
mutex_.lock();
|
2015-09-08 19:36:48 +00:00
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
Status TransactionDBMutexImpl::TryLockFor(int64_t timeout_time) {
|
|
|
|
bool locked = true;
|
|
|
|
|
2015-12-19 01:08:47 +00:00
|
|
|
if (timeout_time == 0) {
|
2016-02-10 02:24:41 +00:00
|
|
|
locked = mutex_.try_lock();
|
2015-09-08 19:36:48 +00:00
|
|
|
} else {
|
2015-12-19 01:08:47 +00:00
|
|
|
// 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.
|
2016-02-10 02:24:41 +00:00
|
|
|
mutex_.lock();
|
2015-09-08 19:36:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
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());
|
2015-12-19 01:08:47 +00:00
|
|
|
|
2016-02-10 02:24:41 +00:00
|
|
|
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();
|
2015-12-19 01:08:47 +00:00
|
|
|
|
2015-09-08 19:36:48 +00:00
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
|
|
|
Status TransactionDBCondVarImpl::WaitFor(
|
|
|
|
std::shared_ptr<TransactionDBMutex> mutex, int64_t timeout_time) {
|
2016-02-10 02:24:41 +00:00
|
|
|
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());
|
2016-02-10 02:24:41 +00:00
|
|
|
std::unique_lock<std::mutex> lock(mutex_impl->mutex_, std::adopt_lock);
|
2015-09-08 19:36:48 +00:00
|
|
|
|
|
|
|
if (timeout_time < 0) {
|
|
|
|
// If timeout is negative, do not use a timeout
|
2016-02-10 02:24:41 +00:00
|
|
|
cv_.wait(lock);
|
2015-09-08 19:36:48 +00:00
|
|
|
} else {
|
|
|
|
auto duration = std::chrono::microseconds(timeout_time);
|
2016-02-10 02:24:41 +00:00
|
|
|
auto cv_status = cv_.wait_for(lock, duration);
|
2015-09-08 19:36:48 +00:00
|
|
|
|
|
|
|
// Check if the wait stopped due to timing out.
|
|
|
|
if (cv_status == std::cv_status::timeout) {
|
2016-02-10 02:24:41 +00:00
|
|
|
s = Status::TimedOut(Status::SubCode::kMutexTimeout);
|
2015-09-08 19:36:48 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-02-10 02:24:41 +00:00
|
|
|
// Make sure unique_lock doesn't unlock mutex when it destructs
|
|
|
|
lock.release();
|
|
|
|
|
2015-09-08 19:36:48 +00:00
|
|
|
// CV was signaled, or we spuriously woke up (but didn't time out)
|
2016-02-10 02:24:41 +00:00
|
|
|
return s;
|
2015-09-08 19:36:48 +00:00
|
|
|
}
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|
2015-09-08 19:36:48 +00:00
|
|
|
|