Suppose I have a class:
class A
{
private:
std::vector<MyObject> history;
std::mutex historyLock;
}
There are multiple threads initialized by that class which acquire the mutex and write to the history vector. Suppose then I have another class where I want to read that list:
class B
{
public:
B(A instanceA)
{
// I want to read the list here in a thread safe way
}
}
My intuition tells me to expose a method in class A called GetHistory(), which would lock the mutex, copy the list and return the copy.
Is there a way to read the list in class B without incurring the cost of a copy operation?
There are several ways to approach this sort of problem. One way is to use a more sophisticated structure to store your history, like an immutable vector. (An immutable vector trades iteration performance for cheap copies.) But using just standard C++, I think the easiest way is to add a traversal member function template to class A that accepts a callback:
template <class F> void TraverseHistory(F&& callback)
{
std::lock_guard guard{ historyMutex };
for (auto const& item : history)
{
callback(item);
}
}
You can also use std::function if you prefer to avoid a function template:
void TraverseHistory(std::function<void(MyObject const&)> const& callback);
Yet another option is to pass a reference to the entire vector to your callback. With that approach, the function template would look something like this:
template <class F> void ReadHistory(F&& callback)
{
std::lock_guard guard{ historyMutex };
callback(std::as_const(history));
}
Related
I want to call methods of some class atomically from two threads.
I have non-thead-safe class, from third-party library, but need to use this class like that:
Main thread:
Foo foo;
foo.method1(); // while calling Foo::method1 object foo is locked for another threads
Second thread:
foo.method2(); // wait while somewere calling another methods from foo
How to use std::atomic at this situation? Or may be another solution (exclude use mutex and lock before and unlock after calling methods from foo)?
You cannot use std::atomic with user-defined types that are not trivially copyable, and the Standard only provides a limited set of specializations for certain fundamental types. Here you can find the list of all the standard specializations of std::atomic.
One approach you may want to consider is to write a general-purpose wrapper that lets you provide callable objects to be executed in a thread-safe manner on the wrapped object. Something along these lines was once presented by Herb Sutter in one of his talks:
template<typename T>
class synchronized
{
public:
template<typename... Args>
synchronized(Args&&... args) : _obj{std::forward<Args>(args)...} { }
template<typename F>
void thread_safe_invoke(F&& f)
{
std::lock_guard<std::mutex> lock{_m};
(std::forward<F>(f))(_obj);
}
// ...
private:
T _obj;
std::mutex _m;
};
This incurs some syntactic overhead in case you only want to call a single function in a thread-safe manner, but it also allows realizing transactions that must be performed atomically and may consist of more than one function call on the synchronized object.
This is how you could use it:
int main()
{
synchronized<std::string> s{"Hello"};
s.thread_safe_invoke([&] (auto& s)
{
std::cout << s.size() << " " << (s + s);
});
}
For a deeper analysis and implementation guidance, you may refer to this article on the subject as well as this one.
Share a std::mutex between the different threads. Where ever you use foo, wrap the calls with a std::unique_lock
in my program I have global data.
Every program module must have read and write access to the data. As of now, I do not use threading, but Qt's signals and slots and therefore - although I did not yet encounter crashes - I think I'll need synchronization somewhen.
Therefore, every module holds the data like this:
const std::vector<T>& data;
where T is a custom class. Therefore, every module can read the data. To keep it consistent, the vector itself is const to prohibit concurrent deletions or removals. Those are done using global functions (like addToData(T elem), removeFromData(int id)) which can be synchronized. Note that the vector itself is declared to be shared by reference, such that changes in one of the global functions above will result in consistent data in every program module.
==> That means that data can be read and added/removed from everywhere in a safe way.
The problem I encountered is modification of the data. The setters of T are aware of the race-conditions. Using data, I want to allow calls like data.at(3).setAttr("hello"), but for constant vectors, at() just returns constant references. Why and how can I make it work? I can cast the constness away, but that feels wrong.
I am also open for suggestions considering my architecture.
This scenario is exactly where you want to cast constness away. You have carefully designed your system to work correctly so don't feel badly about casting away const when you're completely ready for it's and it the right thing to do.
Synchronizing writes leaving reads non-synchronized may/will corrupt memory too.
Casting constancy away smells.
Working low overhead solution (though not well encapsulated) is below. Idea is well summarized in a #JonathanWakely's comment: "add a global function that takes a functor and applies it to the non-const vector"
header.h
struct no_synchronization {
struct mutex {}
struct guard {
guard(mutex&) {}
};
};
struct serialized {
typedef std::mutex mutex;
typedef std::lock_guard<mutex> guard;
};
template <class T, class S = no_synchronization>
class spaghetti {
typedef typename S::mutex mutex;
typedef typename S::guard guard;
static mutex mutex_;
static std::vector<T> vector_;
template <class F>
static void read_global_vec(F const& f) {
guard lock(mutex_);
std::vector<T> const& ref = vector_;
f(ref);
}
template <class F>
static void write_global_vec(F const& f) {
guard lock(mutex_);
f(vector_);
}
}
If the contents of the vector is changing infrequently then you can use copy-on-write with a shared_ptr to keep contention to the minimum.
Since you asked for suggestions
You can wrap vector, with a class that works mostly the same. This would also get rid of the global functions you mention, which is good. If you want the instance of your class to be const, use a mutable vector internally.
const_cast, but try to hide it somewhere in a function.
Store smart pointers. I hope I'm not wrong with this (it's been a while), but I think you can retrieve a non-const element through a const smart pointer.
To elaborate on (1) since I was asked to in the comment:
You need the functionality of vector, it's a pretty good match for your needs. But the interface of vector is clumsy for what you need. This is a situation which is often encountered, and a wrapper is the default solution. A wrapper is a new class, with an interface that matches your needs, but it's implementation is pretty much just delegating all the work to another class. The goal of using a wrapper is to make the wrapper object easier to use right and harder to use wrong. It might look somewhat like this (not tested, will not compile):
class AWrapperForDemonstration
{
public:
MyCustomClass& GetByIndex(int i) const // can throw
{
std::lock_guard<std::mutex> lock(_mutex);
return _storage[i];
}
size_t Size(int i) const
{
std::lock_guard<std::mutex> lock(_mutex);
return _storage.size();
}
void Add(MyCustomClass& addThis)
{
std::lock_guard<std::mutex> lock(_mutex);
_storage.push_back(addThis);
}
bool Remove(MyCustomClass& removeThis)
{
std::lock_guard<std::mutex> lock(_mutex);
auto it =_storage.find(removeThis);
if (it == _storage.end())
return false;
_storage.erase(it);
}
template <F> void ForEach(F const& f) const
{
std::lock_guard<std::mutex> lock(_mutex);
for (auto& i : _storage)
f(i);
}
private:
std::vector<MyCustomClass> _storage;
std::mutex _mutex;
}
My Event Manager
For a event manager I need to store many pointers to functions in a vector to call them when the event is triggered. (I will provide the source code of the EventFunction helper class at the end of this question.)
// an event is defined by a string name and a number
typedef pair<string, int> EventKey;
// EventFunction holds a pointer to a listener function with or without data parameter
typedef unordered_map<EventKey, vector<EventFunction>> ListEvent;
// stores all events and their listeners
ListEvent List;
Registering an listener could be done by calling the first or the second function, depending on if you want receive additional data or not. (This code is from my event manager class.)
public:
typedef void (*EventFunctionPointer)();
typedef void (*EventFunctionPointerData)(void* Data);
// let components register for events by functions with or without data parameter,
// internally simple create a EventFunction object and call the private function
void ManagerEvent::Listen(EventFunctionPointer Function, string Name, int State);
void ManagerEvent::Listen(EventFunctionPointerData Function, string Name, int State);
private:
void ManagerEvent::Listen(EventFunction Function, string Name, int State)
{
EventKey Key(Name, State);
List[Key].push_back(Function);
}
Member Function Pointers
That code doesn't work because I store function pointers but not member function pointers in my List. All these pointers should be member function pointers because a component like ComponentSound will listen to the event "PlayerLevelup" with on of its member functions ComponentSound::PlayerLevelup to play a nice sound if the event is triggered.
A member function pointer in C++ looks like this.
// ReturnType (Class::*MemberFunction)(Parameters);
void (ComponentSound::*PlayerLevelup)();
The problem is, any component class should be able to listen for events, but storing the member function pointers in the event manager requires me to specify the listening class. As you can see in the example, I need to specify ComponentSound but the event manager should simply have a vector of member function pointers to any class.
Question
An Answer to one of these question would help me a lot.
How can I store function pointers to any member function in a vector in my event manager? (Maybe it helps that all the listening functions are inherited from one abstract class Component.)
How can I design my event manager in another way to reach the aimed functionality? (I want to use string and int keys for messages.)
I tried to keep my question general but if you need more informations or code please comment.
Assignments
In my vector of member function pointers I use EventFunction instead of only a pointer to provide two message types. One with, and one without a data parameter.
class EventFunction
{
private: EventFunctionPointer Pointer; EventFunctionPointerData PointerData; bool Data;
public:
EventFunction(EventFunctionPointer Pointer) : Pointer(Pointer), PointerData(NULL), Data(false) { }
EventFunction(EventFunctionPointerData PointerData) : PointerData(PointerData), Pointer(NULL), Data(true) { }
EventFunctionPointer GetFunction() { return Pointer; }
EventFunctionPointerData GetFunctionData() { return PointerData; } bool IsData() { return Data; }
void Call(void* Data = NULL){ if(this->Data) PointerData(Data); else Pointer(); }
};
You will have to use std::function. This is the only way to achieve a generic callback. As soon as you involve function pointers instead of function objects, it is not generic, will never be generic, and can never be made to be generic.
unordered_map<string, vector<std::function<void()>>>
Function pointers are bad and should never be explicitly used in C++, only passed to templates like std::bind and std::function's constructor, and member function pointers are even worse.
You can use functors to achieve this. If you wrap a functor around your member functions you can make a vector out of functors. A functor looks like this:
template <class T> class MyFunctor
{
private:
T* ObjectPtr;
void (T::*MemberFunction) ();
public:
void operator () ()
{
return (*this->ObjectPtr.*this->MemberFunction)();
}
};
So basically a functor overrides the () operator and returns the member function stored in the functor class. Functors can be quite complex if you want them to work with different signatures but in this article you can get further information.
http://www.codeproject.com/Articles/7112/Pointers-to-Member-Functions-and-Functors
Not a direct response, so bear with me.
Before we start: This is generally referred to as the Observer pattern, you might find lots of confused information on the web about it, and many failed implementations, but who knows you might also strike gold.
Okay, so first the question has a fundamental flaw: it fails to consider that capturing object references is tricky, because object lifetimes are bounded.
Therefore, even before we delve into the specifics of an implementation we need to ask ourselves how to handle stale references. There are two basic strategies:
Not having stale references, this implies that registered objects unregister themselves automatically upon destruction. The mechanism can be factored out in a base class.
Having a way to tell good and stale references apart when inspecting them, and lazily collecting the stale ones. The mechanism can be enforced using a shared_ptr/weak_ptr pair and realizing that weak_ptr are observers of the shared_ptr.
Both solutions are viable and neither implementation is perfect. The base class mechanism assumes you can actually modify your class hierarchy while the weak_ptr trick assumes that all observes will be heap-allocated and their lifetime controlled by a weak_ptr.
I will make an example using shared_ptr (and make use of a number of C++11 facilities, though none is mandatory here):
class EventManager {
typedef std::unique_ptr<Observer> OPtr;
typedef std::vector<OPtr> Observers;
public:
// Callback observers of "name"
// Returns the number of observers so invoked
size_t signal(std::string const& name) const {
auto const it = _observers.find(name);
if (it == _observers.end()) { return 0; }
Observers& obs = it->second;
size_t count = 0;
auto invoker = [&count](OPtr const& p) -> bool {
bool const invoked = p->invoke();
count += invoked;
return not invoked; // if not invoked, remove it!
};
obs.erase(std::remove_if(obs.begin(), obs.end(), invoker), obs.end());
if (obs.empty()) { _observers.erase(it); }
return count;
}
// Registers a function callback on event "name"
void register(std::string const& name, void (*f)()) {
_observers[name].push_back(OPtr(new ObserverFunc(f)));
}
// Registers an object callback on event "name"
template <typename T>
void register(std::string const& name, std::shared_ptr<T> const& p, void (T::*f)()) {
_observers[name].push_back(OPtr(new ObserverMember<T>(p, f)));
}
private:
struct Observer { virtual ~Observer() {} virtual bool invoke() = 0; };
struct ObserverFunc: Observer {
ObserverFunc(void (*f)()): _f(f) {}
virtual bool invoke() override { _f(); return true; }
void (*_f)();
};
template <typename T>
struct ObserverMember: Observer {
ObserverT(std::weak_ptr<T> p, void (T::*f)()): _p(p), _f(f) {}
virtual bool invoke() override {
std::shared_ptr<T> p = _p.lock();
if (not p) { return false; }
p->*_f();
return true;
}
std::weak_ptr<T> _p;
void (T::*_f)();
};
// mutable because we remove observers lazily
mutable std::unordered_map<std::string, Observers> _observers;
}; // class EventManager
This is the typical case where you should use polymorphism instead of function (or member function) pointers.
As you noted, your component classes should inherit from a common class Component, which contains virtual method(s) representing the event(s):
class Component
{
public:
virtual void OnPlayerLevelUp()
{
}
};
class ComponentSound : public Component
{
public:
// override it
void OnPlayerLevelUp()
{
// do the actual work
}
};
Your ListEvent type will now look like this:
typedef unordered_map<EventKey, vector<Component*>> ListEvent;
As for the optional void* paramenter in event methods, you can specify it as an optional parameter, but the fact that it's a void* is a bad sign (use of void* can lead to loss of type safety), so I would suggest that you look for a different way to achieve what you want.
I have a framework function which expects an object and a member function pointer (callback), like this:
do_some_work(Object* optr, void (Object::*fptr)()); // will call (optr->*fptr)()
How can I pass a lambda expression to it? Want to do somethink like this:
class MyObject : public Object
{
void mystuff()
{
do_some_work(this, [](){ /* this lambda I want to pass */ });
}
};
The meaning of it all is to not clutter the interface of MyObject class with callbacks.
UPD
I can improve do_some_work in no way because I don't control framework and because actually it isn't one function, there're hundreds of them. Whole framework is based on callbacks of that type. Common usage example without lambdas:
typedef void (Object::*Callback)();
class MyObject : public Object
{
void mystuff()
{
do_some_work(this, (Callback)(MyClass::do_work));
}
void do_work()
{
// here the work is done
}
};
SOLUTION Here's my solution based on Marcelo's answer:
class CallbackWrapper : public Object
{
fptr fptr_;
public:
CallbackWrapper(void (*fptr)()) : fptr_(fptr) { }
void execute()
{
*fptr_();
}
};
class MyObject : public Object
{
void mystuff()
{
CallbackWrapper* do_work = new CallbackWrapper([]()
{
/* this lambda is passed */
});
do_some_work(do_work, (Callback)(CallbackWrapper::execute));
}
};
Since we create the CallbackWrapper we can control it's lifetime for the cases where the callback is used asynchonously. Thanks to all.
This is impossible. The construct (optr->*fptr)() requires that fptr be a pointer-to-member. If do_some_work is under your control, change it to take something that's compatible with a lambda function, such as std::function<void()> or a parameterised type. If it's a legacy framework that isn't under your control, you may be able to wrap it, if it's a function template, e.g.:
template <typename Object>
do_some_work(Object* optr, void (Object::*fptr)());
Then, you can implement a wrapper template:
template <typename F>
void do_some_work(F f) {
struct S {
F f;
S(F f) : f(f) { }
void call() { f(); delete this; }
};
S* lamf = new S(f);
do_some_work(lamf, &S::call);
}
class MyObject // You probably don't need this class anymore.
{
void mystuff()
{
do_some_work([](){ /* Do your thing... */ });
}
};
Edit: If do_some_work completes asynchronously, you must allocate lamf on the heap. I've amended the above code accordingly, just to be on the safe side. Thanks to #David Rodriguez for pointing this out.
There are deeper problems with the approach that you are trying to take than the syntactical mismatch. As DeadMG suggests, the best solution is to improve the interface of do_some_work to take a functor of some sort (std::function<void()> in C++11 or with boost, or even a generic F on which operator() is called.
The solution provided by Marcelo solves the syntactical mismatch, but because the library takes the first element by pointer, it is the responsibility of the caller to ensure that the object will be alive when the callback is executed. Assuming that the callback is asynchronous, the problem with his solution (and other similar alternatives) is that the object can potentially be destroyed before the callback is executed, causing undefined behavior.
I would suggest that you use some form of plimp idiom, where the goal in this case would be to hide the need for callbacks (because the rest of the implementation might not need to be hidden you could use just another class to handle the callbacks but store it by value, if you don't want do have to dynamically allocate more memory):
class MyClass;
class MyClassCallbacks {
MyClass* ptr;
public:
MyClassCallbacks( MyClass* ptr ) : ptr(ptr) {}
// callbacks that execute code on `ptr`
void callback1() {
// do some operations
// update *ptr
}
};
class MyClass {
MyClassCallbacks callbackHandler;
public:
void mystuff() {
do_some_work( &callbackHandler, &MyClassHandler::callback1 );
}
};
In this design, the two classes are separated but represent a unique single entity, so it is fine to add a friend declaration and let MyClassCallbacks access the internal data in MyClass (both of them are one single entity, divided only to provide a cleaner interface, but coupling is already high, so adding the extra coupling requiered by friend is no problem).
Because there is a 1-1 relationship between MyClass and MyClassCallbacks instances, their lifetimes are bound and there would be no lifetime issues, except during destruction. During destruction you must ensure that there is no callback registered that can kick in while the MyClass object is being destroyed.
Since you are at it, you might want to walk the extra mile and do a proper pimpl: move all of the data and implementation into a different type that is held by pointer, and offer a MyClass that stores a pointer and offers just the public functions, implemented as forwarders to the pimpl object. This could be somehow tricky as you are using inheritance, and the pimpl idiom is a bit cumbersome to implement on type hierarchies (if you need to extend MyClass, deriving from Object could be done in the pimpl object, rather than the interface type).
I don't think you can do that. Your do_some_work() is declared to accept pointer to methods of class Object, so such should be provided. Otherwise optr->*fptr is invalid since the lambda is not member of Object. Probably you should try using std::function and adding the needed members of Object in its closure.
You must use std::function<void()>. Both function and member function pointers are highly unsuited to being callbacks.
I'm creating a new class that inherits queue from the STL library. The only addition to the class is a vector. This vector will have the same size of the queue and it will store some integer values that will correspond to each objects in the queue.
Now, I want to override pop() and push(), but I simply want to add more functionality to the parent's class methods.
ex. When pop() is called on the queue object, I also want pop an object from the vector. When push() is called on the queue object, I also want insert a new object into the vector.
How do I do that???
#include <iostream>
#include <iostream>
#include <queue>
#include <vector>
using namespace std;
template <typename type>
class CPU_Q : public queue<type>
{
public:
vector<int> CPU_TIME;
void increaseTime()
{
for(int ndx = 0; ndx < CPU_TIME.size(); ndx++)
{
CPU_TIME[ndx]++;
}
}
void push(type insertMe)
{
//This is what I want to do
super::push(); // or queue::push(); maybe?
CPU_TIME.push_back(0);
}
void pop()
{
//Something very similar to push()
}
}
Many Many thanks in advance
-Tri
You asked about:
void push(type insertMe){
//This is what I want to do
super::push(); // or queue::push(); maybe?
CPU_TIME.push_back(0);
}
That would be more like:
void push(type insertMe) {
queue<type>::push(insertMe);
CPU_TIME.push_back(0);
}
Except you probably want to accept the parameter by const reference:
void push(type const &insertme) {
queue<type>::push(insertMe);
CPU_TIME.push_back(0);
}
That said, the standard container classes aren't really designed for inheritance (e.g. they don't have a virtual dtors), so you'll have to be careful with this -- e.g. when you destroy it, you'll need the static type to be the derived type; you'll get undefined behavior if (for example) you destroy one via a pointer to the base class.
STL queue class in not intended to be extended using inheritance. Look here for more information on that. Besides that std::queue has more than one template argument. Instead of inheriting you could just use std::queue as a member of your template class CPU_Q as follows:
template<typename T>
class CPU_Q
{
std::queue<T> q;
public:
void push( T val )
{
q.push( val );
// additional work
}
};
Simple answer is that it is not possible. STL container classes are not designed to be inherited. Their destructor is not virtual to start. If you really want to do something like this then write a new class which 'contains' the queue and vector , and use this class everywhere. BTW as a side note, there is no super keyword in C++ unlike Java. If you want to call base class method use BaseClassName::methodName();
Unless your new class has a is-a relationship with std::queue, I would strongly consider encapsulating the queue and vector, and providing methods that forward to the appropriate std::queue/std::vector methods, in the order you want them to be called.
Also, if you want this new class to be compatible with standard algorithms, you will have to implement a begin() and end() method that return an iterator type capable of walking your data structure; you may be able to use the existing methods on std::queue/std::vector to accomplish this though.