I have following lock and thread guard implementations:
class Spinlock
{
public:
/* Default constructor/destructor + deleted copy/moving */
void Lock()
{
while (m_flag.test_and_set(std::memory_order_acquire))
{
// spin...
};
}
void Unlock()
{
m_flag.clear(std::memory_order_release);
}
private:
std::atomic_flag m_flag = ATOMIC_FLAG_INIT;
};
template<class ThreadLock>
class ThreadGuard
{
public:
/* Default constructor + deleted copy/moving */
/* Constructor */
ThreadGuard(ThreadLock& lock)
: m_pLock(&lock)
{
m_pLock->Lock();
}
/* Destructor */
~ThreadGuard()
{
m_pLock->Unlock();
}
private:
ThreadLock* m_pLock;
};
Now, lets say I have following piece of code:
void LockDataAndSetX()
{
ThreadGuard lock(m_spinLock);
/* ... operations on data here ...*/
}
{
/* code... */
LockDataAndSetX();
/* more code... */
}
I wander, if compiler desides to inline LockDataAndSetX function, would it translate to below code?
{
/* code... */
ThreadGuard lock(m_spinLock);
/* ... operations on data here ...*/
/* more code... */
}
I ask, because that would be problematic for me, because range of lock will depened on compiler inlining/not-inlining lock function. I would need to remove my thread guard class in that case.
Scope / lifetime of a variable does not depend on inlining. Inlining is an optimization matter and code must have the very same effect independently on whether a compiler applies inlining or not.
You can imagine the effect of inlining more like as follows:
{
/* code... */
{
ThreadGuard lock(m_spinLock);
/* ... operations on data here ...*/
}
/* more code... */
}
Note also that ThreadGuard is a template and template argument deduction for classes (based on constructor arguments) works from C++17.
Related
I'm reading C++ concurrency in action.
It introduces how to implement interrupting thread using std::condition_variable_any.
I try to understand the code more than a week, but I couldn't.
Below is the code and explanation in the book.
#include <condition_variable>
#include <future>
#include <iostream>
#include <thread>
class thread_interrupted : public std::exception {};
class interrupt_flag {
std::atomic<bool> flag;
std::condition_variable* thread_cond;
std::condition_variable_any* thread_cond_any;
std::mutex set_clear_mutex;
public:
interrupt_flag() : thread_cond(0), thread_cond_any(0) {}
void set() {
flag.store(true, std::memory_order_relaxed);
std::lock_guard<std::mutex> lk(set_clear_mutex);
if (thread_cond) {
thread_cond->notify_all();
} else if (thread_cond_any) {
thread_cond_any->notify_all();
}
}
bool is_set() const { return flag.load(std::memory_order_relaxed); }
template <typename Lockable>
void wait(std::condition_variable_any& cv, Lockable& lk);
};
thread_local static interrupt_flag this_thread_interrupt_flag;
void interruption_point() {
if (this_thread_interrupt_flag.is_set()) {
throw thread_interrupted();
}
}
template <typename Lockable>
void interrupt_flag::wait(std::condition_variable_any& cv, Lockable& lk) {
struct custom_lock {
interrupt_flag* self;
// (1) What is this lk for? Why is lk should be already locked when it is used in costume_lock constructor?
Lockable& lk;
custom_lock(interrupt_flag* self_, std::condition_variable_any& cond,
Lockable& lk_)
: self(self_), lk(lk_) {
self->set_clear_mutex.lock();
self->thread_cond_any = &cond;
}
void unlock() {
lk.unlock();
self->set_clear_mutex.unlock();
}
void lock() { std::lock(self->set_clear_mutex, lk); }
~custom_lock() {
self->thread_cond_any = 0;
self->set_clear_mutex.unlock();
}
};
custom_lock cl(this, cv, lk);
interruption_point();
cv.wait(cl);
interruption_point();
}
class interruptible_thread {
std::thread internal_thread;
interrupt_flag* flag;
public:
template <typename FunctionType>
interruptible_thread(FunctionType f) {
std::promise<interrupt_flag*> p;
internal_thread = std::thread([f, &p] {
p.set_value(&this_thread_interrupt_flag);
f();
});
flag = p.get_future().get();
}
void interrupt() {
if (flag) {
flag->set();
}
};
void join() { internal_thread.join(); };
void detach();
bool joinable() const;
};
template <typename Lockable>
void interruptible_wait(std::condition_variable_any& cv, Lockable& lk) {
this_thread_interrupt_flag.wait(cv, lk);
}
void foo() {
// (2) This is my implementation of how to use interruptible wait. Is it correct?
std::condition_variable_any cv;
std::mutex m;
std::unique_lock<std::mutex> lk(m);
try {
interruptible_wait(cv, lk);
} catch (...) {
std::cout << "interrupted" << std::endl;
}
}
int main() {
std::cout << "Hello" << std::endl;
interruptible_thread th(foo);
th.interrupt();
th.join();
}
Your custom lock type acquires the lock on the internal
set_clear_mutex when it’s constructed 1, and then sets the
thread_cond_any pointer to refer to the std:: condition_variable_any
passed in to the constructor 2.
The Lockable reference is stored for later; this must already be
locked. You can now check for an interruption without worrying about
races. If the interrupt flag is set at this point, it was set before
you acquired the lock on set_clear_mutex. When the condition variable
calls your unlock() function inside wait(), you unlock the Lockable
object and the internal set_clear_mutex 3.
This allows threads that are trying to interrupt you to acquire the
lock on set_clear_mutex and check the thread_cond_any pointer once
you’re inside the wait() call but not before. This is exactly what you
were after (but couldn’t manage) with std::condition_variable.
Once wait() has finished waiting (either because it was notified or
because of a spurious wake), it will call your lock() function, which
again acquires the lock on the internal set_clear_mutex and the lock
on the Lockable object 4. You can now check again for interruptions
that happened during the wait() call before clearing the
thread_cond_any pointer in your custom_lock destructor 5, where you
also unlock the set_clear_mutex.
First, I couldn't understand what is the purpose of Lockabel& lk in mark (1) and why it is already locked in constructor of custom_lock. (It could be locked in the very custom_lock constructor. )
Second there is no example in this book of how to use interruptible wait, so foo() {} in mark (2) is my guess implementation of how to use it. Is it correct way of using it ?
You need a mutex-like object (lk in your foo function) to call the interruptiple waiting just as you would need it for the plain std::condition_variable::wait function.
What's problematic (I also read the book and I have doubts about this example) is that the flag member points to a memory location inside the other thread which could finish right before calling flag->set(). In this specific example the thread only exists after we set the flag so that is okay, but otherwise this approach is limited in my opinion (correct me if I am wrong).
I'm trying to make a thread every time a call a function from a class, but i can't pass the function correctly:
file.h
#include <thread>
class Class
{
public:
Class(int a);
void ThreadBase(void (*func));
int CreateThread(void (*func));
};
file.cpp
#include <thread>
Class::Class(int a)
{
/**
* ...
*/
}
void Class:ThreadBase(void (*func))
{
while(1)
{
/**
* ...
*/
}
}
int Class:CreateThread(void (*func))
{
std::thread th(Class::ThreadBase, func);
}
Error:
error: reference to non-static member function must be called
CreateThread should call std::thread with a function and arguments for the function.
The problem is here:
std::thread th(Class::ThreadBase, func);
Class::ThreadBase is not a static function; so it can't be called directly. In this case; CreateThread should call the member function "ThreadBase" of 'this.'
I am working on a c++ (11) project and on the main thread, I need to check the value of two variables. The value of the two variables will be set by other threads through two different callbacks. I am using two condition variables to notify changes of those two variables. Because in c++, locks are needed for condition variables, I am not sure if I should use the same mutex for the two condition variables or I should use two mutex's to minimize exclusive execution. Somehow, I feel one mutex should be sufficient because on one thread(the main thread in this case) the code will be executed sequentially anyway. The code on the main thread that checks (wait for) the value of the two variables wont be interleaved anyway. Let me know if you need me to write code to illustrate the problem. I can prepare that. Thanks.
Update, add code:
#include <mutex>
class SomeEventObserver {
public:
virtual void handleEventA() = 0;
virtual void handleEventB() = 0;
};
class Client : public SomeEventObserver {
public:
Client() {
m_shouldQuit = false;
m_hasEventAHappened = false;
m_hasEventBHappened = false;
}
// will be callbed by some other thread (for exampe, thread 10)
virtual void handleEventA() override {
{
std::lock_guard<std::mutex> lock(m_mutexForA);
m_hasEventAHappened = true;
}
m_condVarEventForA.notify_all();
}
// will be called by some other thread (for exampe, thread 11)
virtual void handleEventB() override {
{
std::lock_guard<std::mutex> lock(m_mutexForB);
m_hasEventBHappened = true;
}
m_condVarEventForB.notify_all();
}
// here waitForA and waitForB are in the main thread, they are executed sequentially
// so I am wondering if I can use just one mutex to simplify the code
void run() {
waitForA();
waitForB();
}
void doShutDown() {
m_shouldQuit = true;
}
private:
void waitForA() {
std::unique_lock<std::mutex> lock(m_mutexForA);
m_condVarEventForA.wait(lock, [this]{ return m_hasEventAHappened; });
}
void waitForB() {
std::unique_lock<std::mutex> lock(m_mutexForB);
m_condVarEventForB.wait(lock, [this]{ return m_hasEventBHappened; });
}
// I am wondering if I can use just one mutex
std::condition_variable m_condVarEventForA;
std::condition_variable m_condVarEventForB;
std::mutex m_mutexForA;
std::mutex m_mutexForB;
bool m_hasEventAHappened;
bool m_hasEventBHappened;
};
int main(int argc, char* argv[]) {
Client client;
client.run();
}
I would like to wrap the following code with clang thread annotations:
std::mutex mutex;
int counter = 0; // should be accessed while the mutex is locked
std::unique_lock<std::mutex> lock(mutex, std::try_to_lock);
if (lock) {
++counter;
}
I want both to use a RAII lock (std::unique_guard) and I also would like to add thread annotations to this code.
class __attribute__((capability("mutex"))) Mutex {
public:
Mutex() = default;
std::mutex &getInternalMutex() { return m_mutex; }
private:
std::mutex m_mutex{};
};
class __attribute__((scoped_lockable)) TryLock {
public:
TryLock(Mutex &mutex)
// PROBLEM HERE: __attribute__((acquire_capability(mutex)))
// is not suitable (lock may fail) but
// __attribute__((try_acquire_capability(true, mutex)))
// cannot be used neither (requires to be used in a method
// returning whether the lock succeed or not)
: m_try_lock(mutex.getInternalMutex(), std::try_to_lock) {}
~TryLock() __attribute__((release_capability)) = default;
bool isLocked() const {
return !!m_try_lock;
}
private:
std::unique_lock<std::mutex> m_try_lock;
};
clang only provides try_acquire_capability which is not suitable here (as it should be used for a function returning a boolean indicating if the lock succeeded or not).
What would be the correct way to annotate this lock?
I use the thread local storage with boost.
I have a global variable :
boost::thread_specific_ptr<MyDataClass> p_timeline_ctx;
and I have the following class, which encapsulates a boost::thread object and contains an additionnal data object :
class MyThread {
private :
boost::thread t;
MyDataClass d;
public :
MyThread():c() {}
void start(void) {
ptr.reset(this->d);
this->t = boost::thread(&MyThread::worker, this);
}
void worker(void) {
// do something
}
};
I do not get any error when compiling. But on runtime, when the worker function exits and the thread ends, I get a "glibc ... free ... invalid pointer" error.
I guess this comes from the fact that, according to the boost doc, the thread_specific_ptr tries to delete the object it points to when threads end. But I do not see how to solve the problem.
The thread specific pointer takes ownership. You could reset it:
p_timeline_ctx.reset(0);
or intialize it with a deep copy in the first place:
ptr.reset(new MyDataStruct(d));
However, you'd be far better off just passing the reference as an argument to the thread pointer.
In fact, the worker is already an instance member function, so, why do you need a thread-specific copy of this:
#include <boost/bind.hpp>
#include <boost/thread.hpp>
#include <iostream>
struct MyDataClass { };
class MyThread {
private :
boost::thread t;
MyDataClass d;
public :
MyThread(): d() {}
void start(void) {
t = boost::thread(&MyThread::worker, this);
}
void worker() {
// just use this->d here
}
};
int main()
{
}
Or using a static thread function:
#include <boost/bind.hpp>
#include <boost/thread.hpp>
#include <iostream>
struct MyDataClass { };
class MyThread {
private :
boost::thread t;
MyDataClass d;
public :
MyThread(): d() {}
void start(void) {
t = boost::thread(&MyThread::worker, boost::ref(d));
}
static void worker(MyDataClass&) {
// do something
}
};
int main()
{
}