Let's say I have one Mutex, two threads, one function and one cycle (Pseudo code).
Function:
void Update(){
Mutex.enter();
...// time: 10 ms
Mutex.leave();
}
Main.cpp:
void main(){
...// Starting thread
while(true)
Update();
}
Thread:
void Thread(void *){
Mutex.enter();
... //
Mutex.leave();
}
But Function calls constantly, so Mutex small time is free. How high chance Thread have to enter in Mutex? If low, how it can be resolved?
If you're using boost threads (link), then I'd use yield(). It'll allow any other "waiting" threads to "get a chance" to run.
There's probably a win32 or pthreads way of doing this too.
Edit: and by the way, use yield() outside of the locks. If it's inside the locks, obviously that would be useless.
Edit2: And here's the functions for different platforms:
Win32: SwitchToThread() msdn link.
Linux/Unix pthreads: `pthread_yield()' link
If you're not on any of those platforms, read the descriptions at those links, and look for a function that does the same thing in your framework.
From the pseudo-code you showed it seems like there's no cooperation between threads. If thread2 is lucky to grab the mutex before the call to the first Update() is placed then for the whole lifetime of thread2 Update() functions will not be called. It looks like a flawed design to me. If thread2 is doing the work and 'main' thread is calling Update() function to monitor and report the progress of whatever is happening in thread2 thread routine, then it would make much more sense to have thread1 (the main one) wait on a update_required signal and thread2 (the one that is progressing with work) would do the work, then fill-in a struct variable with all the data needed to report the progress and signal thread1 to use the data and report the progress. Using a ring buffer of such struct variable could eliminate the need for mutexes altogether.
Related
I am trying to hook a function that is usually being called by multiple threads without any idle time in between. I was wondering what's the safest way to hook the function, preventing other threads (which I do not own) to not execute the code while I am hooking the function.
My initial idea was to suspend the other threads, but this is not ideal in my situation. I decided to use atomic operations. This is some pseudocode I have come up with to test my idea:
#include <thread>
#include <cstdio>
#include <Windows.h>
void hook()
{
puts("Function hooked");
}
void func()
{
puts("Actual function");
}
void __declspec(noreturn) thread()
{
while (true)
func(); //Hammer the function
}
int main()
{
DWORD old;
VirtualProtect(func, 0x5, PAGE_EXECUTE_READWRITE, &old); //change memory protections so we can write
//create the threads and release the handle (we don't own them)
std::thread t{thread};
t.detach();
std::thread s{thread};
s.detach();
std::thread z{thread};
z.detach();
//sleep 1 second to allow `threads t, s, z` to run
Sleep(1000);
//Hook the function
_InterlockedExchange8(reinterpret_cast<char*>(func), 0xe9);
const auto diff = static_cast<ULONG>(reinterpret_cast<ULONG>(hook) - reinterpret_cast<ULONG>(func)) - 5;
_InterlockedExchange(reinterpret_cast<unsigned long*>(reinterpret_cast<PUCHAR>(func) + 1), diff);
//Halt the current thread until program is terminated
WaitForSingleObject(GetCurrentProcess(), INFINITE);
}
This works, but is it safe? Or is it working only because of the time it takes to call puts and return? Is there a better way to do this?
Thanks.
It depends upon a number of factors, and there are a number of possible solutions.
Can the function be written so that it is reentrant? That is, can you make the function such that it doesn't matter if multiple threads are using it simultaneously? The lack of static variables (static constants are ok) and the lack of calls to non-reentrant routines would make it non-reentrant itself. In that case, no synchronization is necessary.
It looks like you are writing the code for the function yourself. Why not just put a static mutex in the function and lock it while you are executing code that violates the reentrant criteria? The critical section might be a very small portion of the whole function, and the thread suspension brief.
It looks like you are writing the code for the other threads. You could share a global mutex that each thread locks when it calls the function.
If the other threads are in separate processes, you should look into the Interprocess Synchronization capabilities in Windows. This would allow you to produce a system mutex object and give it to all the processes for their use to allow synchronized access to the function.
Note that solutions 2, 3 and 4 do suspend the threads, so may not be acceptable in your situation.
Also, note that you detach the threads, but the function is part of your code. Will the threads continue running after your code exits? Those detached threads will then be calling deleted code.
I am creating multiple threads in my program. On pressing Ctrl-C, a signal handler is called. Inside a signal handler, I have put exit(0) at last. The thing is that sometimes the program terminates safely but the other times, I get runtime error stating
abort() has been called
So what would be the possible solution to avoid the error?
The usual way is to set an atomic flag (like std::atomic<bool>) which is checked by all threads (including the main thread). If set, then the sub-threads exit, and the main thread starts to join the sub-threads. Then you can exit cleanly.
If you use std::thread for the threads, that's a possible reason for the crashes you have. You must join the thread before the std::thread object is destructed.
Others have mentioned having the signal-handler set a std::atomic<bool> and having all the other threads periodically check that value to know when to exit.
That approach works well as long as all of your other threads are periodically waking up anyway, at a reasonable frequency.
It's not entirely satisfactory if one or more of your threads is purely event-driven, however -- in an event-driven program, threads are only supposed to wake up when there is some work for them to do, which means that they might well be asleep for days or weeks at a time. If they are forced to wake up every (so many) milliseconds simply to poll an atomic-boolean-flag, that makes an otherwise extremely CPU-efficient program much less CPU-efficient, since now every thread is waking up at short regular intervals, 24/7/365. This can be particularly problematic if you are trying to conserve battery life, as it can prevent the CPU from going into power-saving mode.
An alternative approach that avoids polling would be this one:
On startup, have your main thread create an fd-pipe or socket-pair (by calling pipe() or socketpair())
Have your main thread (or possibly some other responsible thread) include the receiving-socket in its read-ready select() fd_set (or take a similar action for poll() or whatever wait-for-IO function that thread blocks in)
When the signal-handler is executed, have it write a byte (any byte, doesn't matter what) into the sending-socket.
That will cause the main thread's select() call to immediately return, with FD_ISSET(receivingSocket) indicating true because of the received byte
At that point, your main thread knows it is time for the process to exit, so it can start directing all of its child threads to start shutting down (via whatever mechanism is convenient; atomic booleans or pipes or something else)
After telling all the child threads to start shutting down, the main thread should then call join() on each child thread, so that it can be guaranteed that all of the child threads are actually gone before main() returns. (This is necessary because otherwise there is a risk of a race condition -- e.g. the post-main() cleanup code might occasionally free a resource while a still-executing child thread was still using it, leading to a crash)
The first thing you must accept is that threading is hard.
A "program using threading" is about as generic as a "program using memory", and your question is similar to "how do I not corrupt memory in a program using memory?"
The way you handle threading problem is to restrict how you use threads and the behavior of the threads.
If your threading system is a bunch of small operations composed into a data flow network, with an implicit guarantee that if an operation is too big it is broken down into smaller operations and/or does checkpoints with the system, then shutting down looks very different than if you have a thread that loads an external DLL that then runs it for somewhere from 1 second to 10 hours to infinite length.
Like most things in C++, solving your problem is going to be about ownership, control and (at a last resort) hacks.
Like data in C++, every thread should be owned. The owner of a thread should have significant control over that thread, and be able to tell it that the application is shutting down. The shut down mechanism should be robust and tested, and ideally connected to other mechanisms (like early-abort of speculative tasks).
The fact you are calling exit(0) is a bad sign. It implies your main thread of execution doesn't have a clean shutdown path. Start there; the interrupt handler should signal the main thread that shutdown should begin, and then your main thread should shut down gracefully. All stack frames should unwind, data should be cleaned up, etc.
Then the same kind of logic that permits that clean and fast shutdown should also be applied to your threaded off code.
Anyone telling you it is as simple as a condition variable/atomic boolean and polling is selling you a bill of goods. That will only work in simple cases if you are lucky, and determining if it works reliably is going to be quite hard.
Additional to Some programmer dude answer and related to discussion in the comment section, you need to make the flag that controls termination of your threads as atomic type.
Consider following case :
bool done = false;
void pending_thread()
{
while(!done)
{
std::this_thread::sleep(std::milliseconds(1));
}
// do something that depends on working thread results
}
void worker_thread()
{
//do something for pending thread
done = true;
}
Here worker thread can be your main thread also and done is terminating flag of your thread, but pending thread need to do something with given data by working thread, before exiting.
this example has race condition and undefined behaviour along with it, and it's really hard to find what is the actual problem int the real world.
Now the corrected version using std::automic :
std::atomic<bool> done(false);
void pending_thread()
{
while(!done.load())
{
std::this_thread::sleep(std::milliseconds(1));
}
// do something that depends on working thread results
}
void worker_thread()
{
//do something for pending thread
done = true;
}
You can exit thread without being concern of race condition or UB.
I hereby pardon for such a general title.
I am writing a physical simulation application which displays data in 3D using OpenGL, and one of the functions which is responsible for some heavy calculations is appearing to hold the performance down a bit. I would like them to be done "on the background" without freezing the application for a few seconds. However, std::thread doesn't seem to work in my case.
The function I am trying to thread has a lot of computations in it, it allocates some memory here and there, calls other functions and uses classes, if that matters. I've created a wrapper function, from which I try to start a thread:
void WrapperFunction(void)
{
std::thread t(DoSomethingSerious);
t.join();
}
However, it appears that it has zero effect, just like if I called DoSomethingSerious directly.
What could be the problem?
join() waits for the thread to finish, before proceeding. That's what joining a thread means.
You have two options.
1) Instantiating a std::thread, and proceed to do whatever else needs to be done, and only join the thread once everything is done.
2) detach() the thread. The detached thread will continue to execute independently, and cannot be joined any more. In this case, you will have to make other arrangements for waiting until the thread stops.
However, it appears that it has zero effect.
Sure, your code in the main thread is just suspended until everything in the asynchronous thread is finished.
If you have intermediate actions between starting the thread and doing the join(), you should notice the effect:
void WrapperFunction(void) {
std::thread t(DoSomethingSerious);
// Do something else in parallel
t.join();
}
That is because you directly call t.join(). The std::thread::join function waits for the thread to finish before returning. As you yourself notice, the effect is that there is no difference from just calling the function.
More useful would be to do something else between the thread creration and where you wait for the thread. Something like the following pseudo-code:
void WrapperFunction(void)
{
// Create thread
std::thread t(DoSomethingSerious);
// Lots
// of
// code
// doing
// other
// things
// Wait for thread to finish
t.join();
}
I have written a program in QT using several threads for doing important stuff in the background. The target for this program is a BeagleBone Black (Single-Core-CPU). But in my tests on my computer (VM, 4 Cores of i7) the separate threads are already eating up two of the four cores as seen in htop (maybe because in two of them a while(condition){}-loop is running). How can I prevent these threads from eating up all my resources, so that I will be able to run this multi-thread-program without speed loss on a single-core-arm-cpu? How can I find out which threads are eating up all my cpu resources?
As you're using Qt, there's a better possibility for making your threads wait. You could indeed use QWaitConditions.
This allows you to make your thread block until a certain condition is met in another thread for example. This thread then can notify either all threads that are waiting that the condition has been met, and then wake them, or just one depending on your need (though through one QWaitCondition you can't determine/predict which one will be notified, that depends on the OS).
In case you need a more general resource about this topic (idleness), I invite you to read the article In praise of idleness which covers this topic more thoroughly.
Besides using waitConditions you can also use the event loop to sequence the code
What will need to happen is that each function in the form of:
void Worker::foo(){
//some code
while(!stop_condition){}
//other code
}
void Worker::signalCondition(){
stop_condition=true;
}
has to be translated to:
void Worker::foo(){
//some code
}
//actual slot called with queuedConnection
void Worker::signalCondition(){
//other code
}
This means Worker needs to be moved to the other thread or the signalCondition will be called on the wrong thread.
admittedly the code change for using QWaitConditions is simpler:
void Worker::foo(){
//some code
{
QMutexLocker locker(&mutex);
while(!stop_condition){
waitCondition.wait(&mutex);
}
}
//other code
}
void Worker::signalCondition(){
QMutexLocker locker(&mutex);
stop_condition=true;
waitCondition.wakeOne();
}
I'm working on a C/C++ networking project and am having difficulties synchronizing/signaling my threads. Here is what I am trying to accomplish:
Poll a bunch of sockets using the poll function
If any sockets are ready from the POLLIN event then send a signal to a reader thread and a writer thread to "wake up"
I have a class called MessageHandler that sets the signals mask and spawns the reader and writer threads. Inside them I then wait on the signal(s) that ought to wake them up.
The problem is that I am testing all this functionality by sending a signal to a thread yet it never wakes up.
Here is the problem code with further explanation. Note I just have highlighted how it works with the reader thread as the writer thread is essentially the same.
// Called once if allowedSignalsMask == 0 in constructor
// STATIC
void MessageHandler::setAllowedSignalsMask() {
allowedSignalsMask = (sigset_t*)std::malloc(sizeof(sigset_t));
sigemptyset(allowedSignalsMask);
sigaddset(allowedSignalsMask, SIGCONT);
}
// STATIC
sigset_t *MessageHandler::allowedSignalsMask = 0;
// STATIC
void* MessageHandler::run(void *arg) {
// Apply the signals mask to any new threads created after this point
pthread_sigmask(SIG_BLOCK, allowedSignalsMask, 0);
MessageHandler *mh = (MessageHandler*)arg;
pthread_create(&(mh->readerThread), 0, &runReaderThread, arg);
sleep(1); // Just sleep for testing purposes let reader thread execute first
pthread_kill(mh->readerThread, SIGCONT);
sleep(1); // Just sleep for testing to let reader thread print without the process terminating
return 0;
}
// STATIC
void* MessageHandler::runReaderThread(void *arg) {
int signo;
for (;;) {
sigwait(allowedSignalsMask, &signo);
fprintf(stdout, "Reader thread signaled\n");
}
return 0;
}
I took out all the error handling I had in the code to condense it but do know for a fact that the thread starts properly and gets to the sigwait call.
The error may be obvious (its not a syntax error - the above code is condensed from compilable code and I might of screwed it up while editing it) but I just can't seem to find/see it since I have spent far to much time on this problem and confused myself.
Let me explain what I think I am doing and if it makes sense.
Upon creating an object of type MessageHandler it will set allowedSignalsMask to the set of the one signal (for the time being) that I am interested in using to wake up my threads.
I add the signal to the blocked signals of the current thread with pthread_sigmask. All further threads created after this point ought to have the same signal mask now.
I then create the reader thread with pthread_create where arg is a pointer to an object of type MessageHandler.
I call sleep as a cheap way to ensure that my readerThread executes all the way to sigwait()
I send the signal SIGCONT to the readerThread as I am interested in sigwait to wake up/unblock once receiving it.
Again I call sleep as a cheap way to ensure that my readerThread can execute all the way after it woke up/unblocked from sigwait()
Other helpful notes that may be useful but I don't think affect the problem:
MessageHandler is constructed and then a different thread is created given the function pointer that points to run. This thread will be responsible for creating the reader and writer threads, polling the sockets with the poll function, and then possibly sending signals to both the reader and writer threads.
I know its a long post but do appreciate you reading it and any help you can offer. If I wasn't clear enough or you feel like I didn't provide enough information please let me know and I will correct the post.
Thanks again.
POSIX threads have condition variables for a reason; use them. You're not supposed to need signal hackery to accomplish basic synchronization tasks when programming with threads.
Here is a good pthread tutorial with information on using condition variables:
https://computing.llnl.gov/tutorials/pthreads/
Or, if you're more comfortable with semaphores, you could use POSIX semaphores (sem_init, sem_post, and sem_wait) instead. But once you figure out why the condition variable and mutex pairing makes sense, I think you'll find condition variables are a much more convenient primitive.
Also, note that your current approach incurs several syscalls (user-space/kernel-space transitions) per synchronization. With a good pthreads implementation, using condition variables should drop that to at most one syscall, and possibly none at all if your threads keep up with each other well enough that the waited-for event occurs while they're still spinning in user-space.
This pattern seems a bit odd, and most likely error prone. The pthread library is rich in synchronization methods, the one most likely to serve your need being in the pthread_cond_* family. These methods handle condition variables, which implement the Wait and Signal approach.
Use SIGUSR1 instead of SIGCONT. SIGCONT doesn't work. Maybe a signal expert knows why.
By the way, we use this pattern because condition variables and mutexes are too slow for our particular application. We need to sleep and wake individual threads very rapidly.
R. points out there is extra overhead due to additional kernel space calls. Perhaps if you sleep > N threads, then a single condition variable would beat out multiple sigwaits and pthread_kills. In our application, we only want to wake one thread when work arrives. You have to have a condition variable and mutex for each thread to do this otherwise you get the stampede. In a test where we slept and woke N threads M times, signals beat mutexes and condition variables by a factor of 5 (it could have been a factor of 40 but I cant remember anymore....argh). We didn't test Futexes which can wake 1 thread at a time and specifically are coded to limit trips to kernel space. I suspect futexes would be faster than mutexes.