How do I use a boost::thread to execute a function with each thread executing in its own memory space. So that when I allocate a new variable with in the function it only lives as an instance in the executing thread.
Just to clarify I want to spawn threads that execute the same method using boost::thread but I do not want to use locks or semaphores I just want it to execute in a separate space.
Anything you allocate inside the thread function is already local to that function, as long as they're not declared as static. Just write your code as normal (avoiding static local variables) and you'll be fine.
If you need to create a thread that is running completely within its own address space, then what you are looking to do is to create a process, not a thread. Threads by definition are points of execution running within the same address space of the parent process.
If you really need to create threads (i.e. there's still memory and other resources shared between threads), but you also need to have a portion of memory dedicated to a specific thread, then you have few options:
1) as ildjarn suggested, have thread procedure allocate local (or dynamic memory) and write your code so that each thread uses this memory that it allocates for itself
2) Take a look at TLS (Thread Local Storage). It is an API that allows you to create "global" variables which are dedicated to a specific thread. Also some variations of C++ have built-in keywords for declaring variables which use TLS under the hood.
Note that in above options you will not get automatic isolation where a thread would not be able to corrupt another threads memory. The only way to get this isolation is to spawn multiple processes (or switch to one of .NET languages and instantiate multiple AppDomains running within the same process).
Related
I have in a Server object multiple thread who are doing the same task. Those threads are init with a Server::* routine.
In this routine there is a infinite loop with some treatments.
I was wondering if it was thread safe to use the same method for multiple threads ? No wonder for the fields of the class, If I want to read or write it I will use a mutex. But what about the routine itself ?
Since a function is an address, those thread will be running in the same memory zone ?
Do I need to create a method with same code for every thread ?
Ps: I use std::mutex(&Server::Task, this)
There is no problem with two threads running the same function at the same time (whether it's a member function or not).
In terms of instructions, it's similar to if you had two threads reading the same field at the same time - that's fine, they both get the same value. It's when you have one writing and one reading, or two writing, that you can start to have race conditions.
In C++ every thread is allocated its own call stack. This means that all local variables which exist only in the scope of a given thread's call stack belong to that thread alone. However, in the case of shared data or resources, such as a global data structure or a database, it is possible for different threads to access these at the same time. One solution to this synchronization problem is to use std::mutex, which you are already doing.
While the function itself might be the same address in memory in terms of its place in the table you aren't writing to it from multiple locations, the function itself is immutable and local variables scoped inside that function will be stacked per thread.
If your writes are protected and the fetches don't pull stale data you're as safe as you could possibly need on most architectures and implementations out there.
Behind the scenes, int Server::Task(std::string arg) is very similar to int Server__Task(Server* this, std::string arg). Just like multiple threads can execute the same function, multiple threads can also execute the same member function - even with the same arguments.
A mutex ensures that no conflicting changes are made, and that each thread sees every prior change. But since code does not chance, you don't need a mutex for it, just like you don't need a mutex for string literals.
I have a Fortran program that calls a C++ dll to do some mathematical operations on 10000 sets of data. The data sets are totally independent from each other. I was planning to create a thread pool and then send tasks to it. However, the call to the dll will be made more than 1000 times (each call the 10000 sets of data are being processed).
My question is: when I create the thread pool during the first call to the dll, what happens to this thread pool after the function in the dll returns ? Can the second call (and the remaining 998 calls) access the pool that was created during the first call.
You can indeed use the same thread pool, if you set things up right.
Objects created on the stack of the FORTRAN->C++ calling thread will be destroyed as that stack unwinds and control returns to FORTRAN, so it's not a good idea to have the thread pool management data on that stack. You can, however:
launch another thread that creates the thread pool management data/object, or
allocate on the heap (using new) to decouple lifetime from the FORTRAN->C++ calls.
The latter is probably easier and cleaner... a pointer to the heap object/data managing the thread pool can be returned to FORTRAN and used as a "handle" for future calls, indicating the same thread pool should be used.
If you have control over the fortran code, you can save yourself some sneaky hiding of your state you maintain by using 3 functions instead of one.
someStateHandle PrepareBackgroundWork();
// Then you do your actual call series...
DoMyMath(someStateHandle, args...);
// And when you are done with all that, you call
FinalizeBackgroundWork(someStateHandle);
If you do not have control over the fortran code, you will have to decide what you want to keep around (Threadpool stuff or thread handles and a few synchronization objects) and lazily initialize them.
struct MyWorkerContext
{
size_t numberOfWorkerThreads;
std::vector<HANDLE> workerHandles;
// ...
};
static MyWorkerContext* s_context = NULL; // Sorry - looks like a singleton to me.
void DoMyMath( args..)
{
if(NULL == s_context) InitializeContext();
if( NULL != s_context )
{
// do the calculations using all that infrastructure.
}
}
E.g. in DLLMain() or hopefully earlier: clean up s_context.
Last not least, I think there is a "default thread pool", you might be able to use for that as well instead of creating your own.
I have long known that Threads each have separate stack-space, but shared heap-memory.
But I recently found some code that made me question exactly what that meant.
Here is a shortened version of the code:
void SampleFunction()
{
CRemoteMessage rmessage;
rMessage.StartBackgroundAsync(); // Kickoff a background thread.
/* Do other long-running work here...
* but don't leave function SampleFunction
*/
rMessage.GetReply(); // Blocks if needed, but the message-background is mostly done by now.
rMessage.ProcessReply();
}
In this code, the rmessage is a local, stack-variable, but spends most of its time in a background thread. Is this safe?? How exactly is the background thread able to access the stack-variable of this thread?
Generally speaking, the stack and heap are part of the memory space that can be shared between threads. No one is preventing you from sharing stack addressed variables.
Each thread however has its own set of registers, including a stack pointer (and the derivatives), so you can maintain separate stacks if you need (otherwise it would be impossible), so the threads can call functions and do whatever they need. You can choose to break this separation if you want.
I think the confusion here is that you think of the stack of a thread as a separate entity that can only be accessed by the one thread. That's not how this works.
Every process has one large memory space to its use and every thread can read (and write!) everything in this space; the separation into stack-space and heap is a higher level design decision. For the background thread it doesn't matter whether the memory it receives is allocated on another thread's stack or on the heap.
There are even rare situations where you want to create a new stack for a thread yourself - makes no difference to the thread itself.
If I have an C++ object created in the main thread, and then start another thread, and from that thread I call a public member function of the object I created, what happens?
Is it different if the public function has parameters or if it manipulates private object members?
Does it behave differently on windows, linux or mac os?
What happens if the object is created on the stack?
There are two points that matter:
first, as usual, you need to esnure that the lifetime of the instance exceeds the duration of its usage.
second, access to variables across multiples threads need be synchronized to prevent race conditions.
That's all folks.
Each thread has a own stack and thus you can have concurrent streams of execution. It is your own duty to make the object thread-safe.
It does not matter. However, private members are a candidate for race conditions.
If you create an object on the stack, it won't be accessible from another thread.
If I have an C++ object created in the main thread, and then start another thread, and from that thread I call a public member function of the object I created, what happens?
It depends on lifetime of the object.
If the object is created on heap(dynamic memory using new) then the other thread will access the members of the object correctly(assuming no race conditions) unless the lifetime of the object ended by calling delete in the first thread.
If the object is created on stack(locally) in the first thread then you will have a *Undefined Behavior*if the lifetime of the created object ended before being accessed in second thread.
Why can you access the object on stack in second thread?
Each thread has its own stack and unless the object created on stack of thread is valid and alive You would be trying to access an address location which doesn't point to any valid object in second thread.
Note that each process has an address space and all threads in the same process share the same address space, hence the address of the variable can be accessed in the second thread. However, You need to ensure that address contains a valid object.
Is it different if the public function has parameters or if it manipulates private object members?
Access specifiers and multithreading are not related at all.
Same access specifier rules apply in all threads.
Does it behave differently on windows, linux or mac os?
The answer to #1 is guaranteed on all Operating systems.
Compared to the original behaviour there should be no differences if created on the heap. However there are some culprits of course, usually known under the term "thread safety". If you access the same member from different threads, you have to ensurse that accessing the same resources does not lead to a "race condition".
To avoid race conditions you can use different kind of "locks", for instance mutexes etc. When using using lock objects there is another culprit: The danger of "deadlocks", if two accessors wait for each other and the original lock never gets released.
It will work perfectly well. Objects do not belong to any specific thread and can equally well be called from anywhere.
However, and this is important, calling member function on two threads at the same time will cause problems where you update some data in one thread while reading it in another. You need to either arrange your code to ensure this can't happen, or ensure that your threads coordinate access (using mutex most likely)
What happens is exactly what happens if you call it from the same
thread. The same machine code gets executed. The only potential
difference is that you can have several threads accessing the object at
the same time; it's up to you to protect against this (at least if any
of the threads is modifying the object—otherwise, no protection is
needed).
In the case of an object on the stack, you have to consider lifetime
issues, but this is the case anyway; save a pointer to an object on the
stack in a global variable, then leave the scope where the object was
defined, and the global variable becomes a dangling pointer; trying to
access the object through it is undefined behavior (and calling a
non-static member function on it it is considered using it). Whether
the access is from the same thread or a different thread doesn't change
anything.
I need to make use of thread-local storage in a cross-platform project. Under *IX I am using pthreads and can avoid memory leaks thanks to the nice destructor function pointer passed as the second argument to pthread_key_create, but in Windows TlsAlloc has no such thing. Nor can I find a general place where any function is called on thread exit (otherwise I would homebrew some list of function pointers that get called at exit).
As it stands it seems that I have basically a situation where in order to actually use thread local storage I need to allocate my own space on the heap and pass a pointer to TlsSetValue, but if the thread exits ... I have no way of ensuring the memory was freed (other than someone explicitly calling TlsGetValue and delete/free/HeapFree/etc at the end of the thread function.
Does anyone know of a better way?
You can get yourself a nice "finalizer" to get rid of thread-specific resources, even if the thread is terminated: use RegisterWaitForSingleObject to wait on a copy (via DuplicateHandle) of the threads' handle - you have to use the cloned handle, cause registered waits can't handle handle {no pun intended} closing.
Use a heap allocated structure/record to hold the finalized resources, the handle waited for and the wait handle itself, cause the finalizer will run in the system threadpool, NOT the finalized thread (which will be already dead by the time). And don't forget to finalize the finalizer :)
The entry point of a DLL (DLLmain) is called on thread exit with a reason code of DLL_THREAD_DETACH. It is fairly straightforward to write a DLL that keeps track of functions to call on thread exit.
Alternatively, use Boost.Thread and the boost::this_thread::at_thread_exit function to register a function to be called on thread exit, or use boost::thread_specific_ptr to wrap the TLS usage entirely.