I'm new to threading in C++, and I'm trying to get a clear picture about how memory is shared/not shared between threads. I'm using std::thread with C++11.
From what I've read on other SO questions, stack memory is owned by only one thread and heap memory is shared between threads. So from what I think I understand about the stack vs. the heap, the following should be true:
#include <thread>
using namespace std;
class Obj {
public:
int x;
Obj(){x = 0;}
};
int main() {
Obj stackObj;
Obj *heapObj = new Obj();
thread t([&]{
stackObj.x++;
heapObj->x++;
});
t.join();
assert(heapObj->x == 1);
assert(stackObj.x == 0);
}
forgive me if I screwed up a bunch of stuff, lambda syntax is very new to me. But hopefully what I'm trying to do is coherent.
Would this perform as I expect? And if not, what am I misunderstanding?
Memory is memory. An object in C++ occupies some location in memory; that location may be on a stack or on the heap, or it may have been statically allocated. It doesn't matter where the object is located: any thread that has a reference or pointer to the object may access the object. If two threads have a reference or a pointer to the object, then both threads may access it.
In your program, you create a worker thread (by constructing a std::thread) that executes the lambda expression you provide it. Because you capture both stackObj and heapObj by reference (using the [&] capture default), that lambda has references to both of those objects.
Those objects are both located on the main thread's stack (note that heapObj is a pointer-type object that is located on the main thread's stack and points to a dynamically allocated object that is located on the heap). No copies of these objects are made; rather, your lambda expression has references to the objects. It modifies the stackObj directly and modifies the object pointed to by heapObj indirectly.
After the main thread joins with the worker thread, both heapObj->x and stackObj.x have a value of 1.
If you had used the value capture default ([=]), your lambda expression would have copied both stackObj and heapObj. The expression stackObj.x++ in the lambda expression would increment the copy, and the stackObj that you declare in main() would be left unchanged.
If you capture the heapObj by value, only the pointer itself is copied, so while a copy of the pointer is used, it still points to the same dynamically allocated object. The expression heapObj->x++ would dereference that pointer, yielding the Obj you created via new Obj(), and increment its value. You would then observe at the end of main() that heapObj->x has been incremented.
(Note that in order to modify an object captured by value, the lambda expression must be declared mutable.)
I agree with James McNellis that heapObj->x and stackObj.x will be 1.
Furthermore, this code only works because you join immediately after spawning the thread. If you started the thread and then did more work while it runs, an exception could unwind the stack and suddenly the new thread's stackObj is invalid. That is why sharing stack memory between threads is a bad idea even if it's technically possible.
Related
I am working on a simple idea and I came across this problem. What happens if after an async call as shown below the program exits without calling shared_future.get()?
Will I have a memory leak?
//async function
std::shared_future<double*> sharedFutures = std::async(std::launch::async, myAsyncFunc, argument1, argument2);
if ( realtimeCondition )
{
//what happens to sharedFutures memory allocation after exiting
//memory leak?
return 0;
}
//getting results
for (sharedFuture : sharedFutures )
double* res = sharedFuture.get();
return 0;
shared_future to some extend mimics std::shared_ptr. They both manage a shared resource. The resource is released when the last shared_x is destroyed. This is checked in the destructor (cppreference: https://en.cppreference.com/w/cpp/thread/shared_future/%7Eshared_future):
~shared_future(); (since C++11)
If *this is the last object referring to the shared state, destroys the shared state. Otherwise does nothing.
If a class manages a resource it should release it in the destructor. Thats true for all classes. The difference here is that the same resource is shared between potentially many objects. So each object has to check if it is the last one to own the resource before it can destroy it.
hence, shared_future destructors are called when exiting and not when having collected the futures via get()?
It would be bad and weird if an object suddenly destroys itself when you call one of its methods. Here specifically, both shared_future and shared_ptr would be practically useless when everytime you access the object they manage that object gets destroyed. The shared_future in your example gets destroyed when it goes out of scope.
If I understand your question correctly calling get() on future will change state->retrieved of future to true but not calls destruction. Destruction of future of any type doesn't depend on its own state.
As an example in pseudocode:
MultiThreadedWorker worker;
Foo()
{
const Vector position = CreatePosition();
worker.StartWorker(Position);
}
MultiThreadedWorker::StartWorker(const Vector& myPosition)
{
... Do a bunch of async work that keeps referencing myPosition ...
}
This seems to be working for now, but I don't understand why because it seems that myPosition would end up pointing to nothing long before StartWorker completed.
Assuming this isn't safe, is there any solution other than just passing around everything by value or ensuring it's all on the heap?
std::async copies const references
So yes, it is safe. For a discussion of why it does, see Why does std::async copy its const & arguments?
It is programmers responsibility to ensure that variable live long enough so that it is not destroyed before any access through pointers or references. This can be achieved through at least by one of the following:
Ensure the thread ends before destroying the variable. You can run .join() on the thread before leaving the scope.
Create object on the heap. Create it using make_shared and pass shared_ptr. This ensures the object lives until the last reference is destroyed.
Note that there is another problem with threads and shared objects. If one thread writes when another thread reads to the same object, then it is a data race which is Undefined Behavior. Thread synchronization mechanisms such as std::mutex can be used to avoid this.
Lines from Anthony Williams book:
The following example shows the use of std::move to transfer ownership
of a dynamic object into a thread:
void process_big_object(std::unique_ptr<big_object>);
std::unique_ptr<big_object> p(new big_object);
p->prepare_data(42);
std::thread t(process_big_object,std::move(p));
By specifying std::move(p) in the std::thread constructor, the
ownership of the big_object is transferred first into internal
storage for the newly created thread and then into
process_big_object.
I understand stack and heap; any idea, what actually is this internal storage ?
Why can't they transfer the ownership directly to process_big_object?
It means that the object will temporarily belong to the std::thread object until the thread actually starts.
Internal storage here refers to the memory associated to the std::thread object. It could be a member variable, or just held in the stack during the constructor. Since this is implementation dependant, the general, and non-commital, "internal storage" term is used.
All arguments to a thread are copied into some internal memory held by the std::thread object, so it can be passed to the thread function.
That internal memory is owned by the std::thread object, before the ownership is passed on to the actual thread function.
Why can't they transfer the ownership directly to process_big_object?
Because there is no line in the code snippet where process_big_object is called as a function. The last line of the snippet calls the std::thread constructor. It will set in motion a chain of events that eventually will cause process_big_object(p) to be called in the new thread; but that call is not visible here.
Does there exist a standard (any C++ standard) way to register a callback, that gets called shortly before any objects with automatic storage duration are destroyed as part of normal program termination?
EDIT:
To make this more clear. It's a multi-threaded application. Some objects may have pushed functors into a thread pool, that reference them (functor accesses the "originator" object). The thread pool object is static, so it gets destroyed after main() returns and so after all these objects who pushed functors into the thread pool, that are referencing them, have already been destroyed. The thread pool is flushed upon termination and so the functors have dangling references to "originator" objects in them.
std::atexit should do what you want:
Registers the function pointed to by func to be called on normal program termination (via std::exit() or returning from the cpp/language/main function)
http://en.cppreference.com/w/cpp/utility/program/atexit'
you may want to put something on std::terminate_handler as well.
http://en.cppreference.com/w/cpp/error/terminate_handler
I'm building a multiple-producer single-consumer mechanism.
I want to do something like this, suppose I have access to an instance of boost lockfree queue available for both threads and a synchronizing condition variable:
Thread 1 (producer):
Object * myObj = new Object();
lockfree_queue.push(myObj);
condition_variable.notify();
Thread 2 (consumer):
condition_variable.wait();
Object * myObj = lockfree_queue.pop();
...
delete myObj;
Is there a chance that on a multi-core system Thread 2 shall see myObj as pointing to memory that is uninitialized or to object that is partially initialized (suppose it has some member variables)?
Once new returns and gives you a pointer, the object is fully constructed.
If there's uninitialized members in the object, then it's the fault of the constructor for not initializing them.
And it shouldn't be a problem even if the queue contained object instances instead of pointers, as the push call would be fully done before you notify the condition variable, so the other thread will not even pop the queue until the object is pushed.