So I am using a variable
std::vector<pthread_t> preallocatedThreadsPool;
to hold all the pthreads,
then I use a for loop
preallocatedThreadsPool.resize(preallocatThreadsNumber); // create a threadpoOl
for(pthread_t i : preallocatedThreadsPool) {
pthread_create(&i, NULL, threadFunctionUsedByThreadsPool, NULL);
}
to create the threads pool,
the question is how do I really destory it, for example, when i send signal to the program then i need to manual handle the program to stop all the preallocated pthreads?
I have tried to use another for loop and inside the for loop to call pthread_exit(i),
but the IDE, tell me the for loop will only execute once, which obviously not working
I have tried to use preallocatedThreadsPool.clear() , to clean the vector, however when i use
gdb tool to debug it, inside the info threads , the threads are still there?
is there a good way to destory all the preallocated pthreads in my case?
Threads have to exit themselves. You can't exit another thread.
You can use pthread_join to wait for a thread to exit, or pthread_detach to say that you're never going to call pthread_join. You have to call one of these, or it leaks the thread. pthread_join destroys the thread; pthread_detach doesn't destroy the thread (obviously) but it allows the thread to destroy itself when it exits.
Since this is a thread pool, you must have a queue of things you want the threads in the pool to do. You can add special "please exit" items to the end of the queue (or the beginning), and then wait for the threads to exit. Make it so the threads exit when they see a "please exit" item in the queue.
It's all about thread synchronization. The proper way is that you have to have a global flag (a condition variable or a Win32 Event for example) that threads must periodically check and if set, terminate. When a thread is exiting, you must also wait for it to do so, so each thread should signal another event when "I'm done".
After that, any "handle" allocated to pthread or to std::thread or to CreateThread can be destroyed. In std::thread, you can detach and forget about the handle.
Even if you can kill the thread immediately by a function such as TerminateThread (there should be something similar in pthreads), this is very bad, for you will have leaked memory, possibly.
Related
I have working on a state design pattern in C++ where I have multiple states. Some states have thread routine bounded by pthread_create. Now there are cases where one state make a transition to another state and thus the thread needs to be stopeed and memory needs to be cleaned by pthread_join.
So in summary I need to stop the thread from the thread-routine itself.
How can I achieve this?
Or is there a way that when the thread-routine is completed the memory clean-up happens automatically?
PS: Problem is, when I make a state transition to another state from the thread routine current state destructor is called. Inside the destructor of the current state I need to stop and join the thread. Otherwise there is a memory leak happening.
So in summary I need to stop the thread from the thread-routine itself. How can I achieve this?
Return from the function that is being executed at the bottom of the thread.
memory needs to be cleaned
You can clean up the thread after it has terminated by joining it from another thread. You can avoid doing that by detaching the thread before terminating it.
P.S. Prefer using the portable std::thread (or std::jthread) instead of system specific threading API.
can u add share code how to terminate a thread from the routine itself using std::thread
Example:
auto thread_fun = [] {
return; // this terminates the thread
};
std::thread t(thread_fun);
t.join(); // this waits for the thread to end, and cleans it up
There are a lot of Qt multi-threading tutorials out there that state that a QThread can be stopped safely using the following two lines.
qthread.quit(); // Cause the thread to cease.
qthread.wait(); // Wait until the thread actually stops to synchronize.
I have a lot of code doing this, and in most cases of stopping thread, I'll always set my own cancel flag and check it often during execution (as is the norm). Until now, I was thinking that calling quit would perhaps cause the thread to simply no longer execute any waiting signals (e.g. signals that are queued will no longer have their slots called) but still wait on the currently executing slot to finish.
But I'm wondering if I was right or if quit() actually stops the execution of the thread where it's at, for instance if something is unfinished, like a file descriptor hasn't been closed, it definitely should be, even though in most cases my worker objects will clean up those resources, I'd feel better if I knew exactly how quit works.
I'm asking this because QThread::quit() documentation says that it's "equivalent to calling QThread::exit(0)". I believe this means that the thread would immediately stop where it's at. But what would happen to the stackframe that quit was called in?
QThread::quit does nothing if the thread does not have an event loop or some code in the thread is blocking the event loop. So it will not necessarily stop the thread.
So QThread::quit tells the thread's event loop to exit. After calling it the thread will get finished as soon as the control returns to the event loop of the thread.
You will have to add some kind of abort flag if you are blocking event loop for example by working in a loop. This can be done by a boolean member variable that is public or at least has a public setter method. Then you can tell the thread to exit ASAP from outside (e.g. from your main thread) by setting the abort flag. Of course this will require your thread code to check the abort flag at regular intervals.
You may also force a thread to terminate right now via QThread::terminate(), but this is a very bad practice, because it may terminate the thread at an undefined position in its code, which means you may end up with resources never getting freed up and other nasty stuff. So use this only if you really can't get around it. From its documentation:
Warning: This function is dangerous and its use is discouraged. The thread can be terminated at any point in its code path. Threads can be terminated while modifying data. There is no chance for the thread to clean up after itself, unlock any held mutexes, etc. In short, use this function only if absolutely necessary.
I think this is a good way to finish a thread when you are using loops in a thread:
myThread->m_abort = true; //Tell the thread to abort
if(!myThread->wait(5000)) //Wait until it actually has terminated (max. 5 sec)
{
myThread->terminate(); //Thread didn't exit in time, probably deadlocked, terminate it!
myThread->wait(); //We have to wait again here!
}
In case, if you want to use Qt's builtin facility then try QThread::requestInterruption().
Main thread
struct X {
QThread m_Thread;
void Quit ()
{
m_Thread.quit();
m_Thread.requestInterruption();
}
};
Some Thread referred by X::m_Thread
while(<condition>) {
if(QThread::currentThread()->isInterruptionRequested())
return;
...
}
As per the documentation:
void QThread::requestInterruption()
Request the interruption of the thread. That request is advisory and it is up to code running on the thread to decide if and how it should act upon such request. This function does not stop any event loop running on the thread and does not terminate it in any way.
In my programme, I handle new threads with
pthread_t thread;
pthread_create(&thread, NULL,
c->someFunction, (void *) fd); //where fd is ID of the thread
The question is quite simple - if I just let the someFunction to finish, is it needed then in C++ to call something e.g. join or anything else, to prevenet memory leaks or is the memory freed automatically??
From the opengroup page for pthread_join,
The pthread_join() function provides a simple mechanism allowing an
application to wait for a thread to terminate. After the thread
terminates, the application may then choose to clean up resources that
were used by the thread. For instance, after pthread_join() returns,
any application-provided stack storage could be reclaimed.
The pthread_join() or pthread_detach() function should eventually be
called for every thread that is created with the detachstate attribute
set to PTHREAD_CREATE_JOINABLE so that storage associated with the
thread may be reclaimed.
and from the man page of pthread_join
Failure to join with a thread that is joinable (i.e., one that is not
detached), pro‐
duces a "zombie thread". Avoid doing this, since each zombie thread consumes some
system resources, and when enough zombie threads have accumulated, it will no longer
be possible to create new threads (or processes).
There is no pthreads analog of waitpid(-1, &status, 0), that is, "join with any ter‐
minated thread".
If you believe you need this functionality, you probably need to
rethink your application design.
If you do pthread_detach,
The pthread_detach() function shall indicate to the implementation
that storage for the thread thread can be reclaimed when that thread
terminates
If you don't detach or join a joinable thread, it can cause waste of resources
pthread_create(&thread, NULL, AcceptLoop, (void *)this);
I have declared like this and inside of the AcceptLoop function I have infinity while loop. I'd like to close this thread when the server is closed. I have read pthread_cancel and pthread_join but I am not sure which one is better and safer. I would like to hear some detailed instructions or tutorials. Thanks in advance.
You don't need to do anything, just returning from the thread function will end the thread cleanly. You can alternatively call pthread_exit() but I'd rather return.
pthread_cancel() is scary and complicated/hard to get right. Stay clear if possible.
pthread_join() is mostly needed if you want to know when thread finishes and are interested in the return value.
Ooops, I'm wrong. It's been some time. In order for what I said to be true, you must detach from your thread. Otherwise you'll need to call pthread_join:
Either pthread_join(3) or
pthread_detach() should be called for
each thread
that an application creates, so that system resources for the thread
can be
released. (But note that the resources of all threads are freed
when the
process terminates.)
http://www.kernel.org/doc/man-pages/online/pages/man3/pthread_detach.3.html
I believe you would like to exit the worker thread by signalling from the main thread.
Inside AcceptLoop instead of looping infinitiely you loop on a condition, you can set the condition through your main thread, You will have to use some synchronization for this variable. Once the variable is set from main thread the worker thread AcceptLoop would break out and you can then call pthread_exit.
if you would like your main thread to wait for child thread to exit you can use pthread_join to do so.
In general, A child thread can exit in three conditions:
calling pthread_exit.
calling pthread_cancel.
The thread function returns.
I have a TCP Server application that serves each client in a new thread using POSIX Threads and C++.
The server calls "listen" on its socket and when a client connects, it makes a new object of class Client. The new object runs in its own thread and processes the client's requests.
When a client disconnects, i want some way to tell my main() thread that this thread is done, and main() can delete this object and log something like "Client disconnected".
My question is, how do i tell to the main thread, that a thread is done ?
The most straightforward way that I can see, is to join the threads. See here. The idea is that on a join call, a command thread will then wait until worker threads exit, and then resume.
Alternatively, you could roll something up with some shared variables and mutexes.
If the child thread is really exiting when it is done (rather than waiting for more work), the parent thread can call pthread_join on it which will block until the child thread exits.
Obviously, if the parent thread is doing other things, it can't constantly be blocking on pthread_join, so you need a way to send a message to the main thread to tell it to call pthread_join. There are a number of IPC mechanisms that you could use for this, but in your particular case (a TCP server), I suspect the main thread is probably a select loop, right? If that's the case, I would recommend using pipe to create a logical pipe, and have the read descriptor for the pipe be one of the descriptors that the main thread selects from.
When a child thread is done, it would then write some sort of message to the pipe saying "I'm Done!" and then the server would know to call pthread_join on that thread and then do whatever else it needs to do when a connection finishes.
Note that you don't have to call pthread_join on a finished child thread, unless you need its return value. However, it is generally a good idea to do so if the child thread has any access to shared resources, since when pthread_join returns without error, it assures you that the child thread is really gone and not in some intermediate state between having sent the "I'm Done!" message and actually having exited.
pthreads return 0 if everything went okay or they return errno if something didn't work.
int ret, joined;
ret = pthread_create(&thread, NULL, connect, (void*) args);
joined = pthread_join(&thread, NULL);
If joined is zero, the thread is done. Clean up that thread's object.
While it is possible to implement IPC mechanisms to notify a main thread when other threads are about to terminate, if you want to do something when a thread terminates you should try to let the terminating thread do it itself.
You might look into using pthread_cleanup_push() to establish a routine to be called when the thread is cancelled or exits. Another option might be to use pthread_key_create() to create a thread-specific data key and associated destructor function.
If you don't want to call pthread_join() from the main thread due to blocking, you should detach the client threads by either setting it as option when creating the thread or calling pthread_detach().
You could use a queue of "thread objects to be deleted", protect access to the queue with a mutex, and then signal a pthread condition variable to indicate that something was available on the queue.
But do you really want to do that? A better model is for each thread to just clean up after itself, and not worry about synchronizing with the main thread in the first place.
Calling pthread_join will block execution of the main thread. Given the description of the problem I don't think it will provide the desired solution.
My preferred solution, in most cases, would be to have the thread perform its own cleanup. If that isn't possible you'll either have to use some kind of polling scheme with shared variables (just remember to make them thread safe, hint:volatile), or perhaps some sort of OS dependant callback mechanism. Remember, you want to be blocked on the call to listen, so really consider having the thread clean itself up.
As others have mentioned, it's easy to handle termination of a given thread with pthread_join. But a weak spot of pthreads is funneling information from several sources into a synchronous stream. (Alternately, you could say its strong spot is performance.)
By far the easiest solution for you would be to handle cleanup in the worker thread. Log the disconnection (add a mutex to the log), delete resources as appropriate, and exit the worker thread without signaling the parent.
Adding mutexes to allow manipulation of shared resources is a tough problem, so be flexible and creative. Always err on caution when synchronizing, and profile before optimizing.
I had exactly the same problem as you described. After ~300 opened client connections my Linux application was not able to create new thread because pthread_join was never called. For me, usage of pthread_tryjoin_np helped.
Briefly:
have a map that holds all opened thread descriptors
from the main thread before new client thread is opened I iterate through map and call pthread_tryjoin_np for each thread recorded in map. If thread is done the result of call is zero meaning that I can clean up resources from that thread. At the same time pthread_tryjoin_np takes care about releasing thread resources. If pthread_tryjoin_np call returns number different from 0 this means that thread is still running and I simply do nothing.
Potential problem with this is that I do not see pthread_tryjoin_np as part official POSIX standard so this solution might not be portable.