I am currently designing a small line following robot that navigates via IR beacons. It is all coded in C++ however integrating the line following and IR receiving seems to have broken it. The IR uses an interrupt service routine to look for an IR signal using an interval timer and SIGALRM. The pathfinding function, along with several of the other robot operations, use sleep(). It has now come to my attention that you cannot use SIGALRM and sleep() in the same program as the SIGALRM wakes the process up prematurely. Is there a good workaround for this besides simply ridding the whole program of sleep() functions?
One band-aid fix is to use the nanosleep function instead of sleep. If nanosleep wakes up prematurely, it stores the remaining time into the time structure, so you can re-try. You can wrap this in your own function that resembles sleep. Since nanosleep isn't ever implemented with SIGALRM, there is no reason why it would wake up prematurely. Be sure to use sigaction to set up your alarm signal handler, and specify SA_RESTART in the flags, all the same. This allows your signal not to disturb restartable system calls.
Related
Thread A executes a blocking call in a loop, until Thread B signals it to continue with the rest of the execution.
I tried the classic approach of an signal handler, which will change a condition variable, so I can test the condition before the the next call starts.
The problem now arises in the case, when the signal arrives after the check of the condition, but before the blocking call.
Short pseudo code example of the problem:
while(!isInterrupted){
raise(SIGINT)
block()
}
Assuming I cannot access or change the implementation of the blocking code and the blocking call doesn't provide an internal timeout functionality, which the signal handler could set to the minimal value, what would be the correct way for C and C++ to handle this?
Signals are used as the blocking call may only be woken up by receiving a SIGINT.
Thank you in advance for your help.
If you can modify the calling assemblies of your libc like I have with https://github.com/pskocik/musl, then you can eliminate this time-of-check to time-of-use problem by having your signal handler call a special function (provided in the modified libc) that'll break the system call if the signal is received while your code is in the function call wrapper after the check but not in kernel mode yet (in kernel mode, blocking calls are naturally broken by signal deliveries naturally).
Without access to your libc (/ you're building purely on top of POSIX), I believe the best you can do is a protocol-based solution:
setup a mechanism by which signal receivers acknowledge signal receipts
have the signal-sending code repeat (preferably with some sleeping) until receipt is acknowledged
That might not be the easiest to set up though (essentially, you'd be fighting POSIX to a degree). If you can afford it, doing the blocking operation in a new thread should be simpler, and pthread_cancel, unlike pthread_kill, should be able to reliably elicit a response (in this case, complete thread cancellation) in the target, unlike pthread_kill.
The downside of using a separate thread is it will be a bit more resource hungry.
Stop using blocking calls, then switch to actual sychronisation primitives.
Please look at mutexes and condition variables for this.
I want to profile my daemon program, that pauses the main thread:
sigset_t signal_mask;
sigemptyset(&signal_mask);
sigaddset(&signal_mask, SIGTERM);
sigaddset(&signal_mask, SIGINT);
int sig;
sigwait(&signal_mask, &sig);
All other threads simply block all signals.
As far as I know the profiler uses SIGPROF signal for its operations. If I start profiling with such a code, the output .prof file is empty:
env CPUPROFILE=daemon.prof ./daemon
How should I properly handle signals in main thread and other threads to enable profiling? Or may be an issue is somewhere else?
All other threads simply block all signals.
You simply need to unblock SIGPROF in all threads (or in those that you want to profile). We were just solving exactly the same problem in a multi-threaded daemon.
I need to see more of your code, but your statement that "All other threads simply block all signals" raises...signals.
You have to remember that most system calls were created before the concept of threads existed. Signal handling is one of them. Thus, when you block a signal on ANY thread, it's likely blocked for ALL threads.
In fact, check out the signal(2) manpage:
The effects of signal() in a multithreaded process are unspecified.
Yes, this is sad, but it is the price you must pay for using a low-overhead statistical sampling profiler. And working around it is very easy: just remove SIGPROF (or SIGALRM if you are using the REAL mode) from your signal mask set and you should be fine.
And in general, unless you absolutely have to, you should not be doing process-level signal masking in anything other than the main thread...where "main" doesn't necessarily mean the thread that MAIN() is running in, but rather, the thread you consider the "boss" of all the others, for reasons you have made all too clear already. :)
You can also try using the pthread library's sigmask wrapper pthread_sigmask, but it is unclear to me how well it works in situations such as a child thread REMOVING an entry from a sigmask (pthreads inherit their parent's pthread sigmask).
Preface
I have a multi-threaded application running via Boost.Asio. There is only one boost::asio::io_service for the whole application and all the things are done inside it by a group of threads. Sometimes it is needed to spawn child processes using fork and exec. When child terminates I need to make waitpid on it to check exit code an to collect zombie. I used recently added boost::asio::signal_set but encountered a problem under ancient systems with linux-2.4.* kernels (that are unfortunately still used by some customers). Under older linux kernels threads are actually a special cases of processes and therefore if a child was spawned by one thread, another thread is unable to wait for it using waitpid family of system calls. Asio's signal_set posts signal handler to io_service and any thread running this service can run this handler, which is inappropriate for my case. So I decided to handle signals in old good signal/sigaction way - all threads have the same handler that calls waitpid. So there is another problem:
The problem
When signal is caught by handler and process is successfully sigwaited, how can I "post" this to my io_service from the handler? As it seems to me, obvious io_service::post() method is impossible because it can deadlock on io_service internal mutexes if signal comes at wrong time. The only thing that came to my mind is to use some pipe or socketpair to write notifications there and async_wait on another end as it is done sometimes to handle signals in poll() event loops.
Are there any better solutions?
I've not dealt with boost::asio but I have solved a similar problem. I believe my solution works for both LinuxThreads and the newer NPTL threads.
I'm assuming that the reason you want to "post" signals to your *io_service* is to interrupt an system call so the thread/program will exit cleanly. Is this correct? If not maybe you can better describe your end goal.
I tried a lot of different solutions including some which required detecting which type of threads were being used. The thing that finally helped me solve this was the section titled Interruption of System Calls and Library Functions by Signal Handlers of man signal(7).
The key is to use sigaction() in your signal handling thread with out SA_RESTART, to create handlers for all the signals you want to catch, unmask these signals using pthread_sigmask(SIG_UNBLOCK, sig_set, 0) in the signal handling thread and mask the same signal set in all other threads. The handler does not have to do anything. Just having a handler changes the behavior and not setting SA_RESTART allows interruptible systems calls (like write()) to interrupt. Whereas if you use sigwait() system calls in other threads are not interrupted.
In order to easily mask signals in all other threads. I start the signal handling thread. Then mask all the signals in want to handle in the main thread before starting any other threads. Then when other threads are started they copy the main thread's signal mask.
The point is if you do this then you may not need to post signals to your *io_service* because you can just check your system calls for interrupt return codes. I don't know how this works with boost::asio though.
So the end result of all this is that I can catch the signals I want like SIGINT, SIGTERM, SIGHUO and SIGQUIT in order to perform a clean shutdown but my other threads still get their system calls interrupted and can also exit cleanly with out any communication between the signal thread and the rest of the system, with out doing anything dangerous in the signal handler and a single implementation works on both LinuxThreads and NPTL.
Maybe that wasn't the answer you were looking for but I hope it helps.
NOTE: If you want to figure out if the system is running LinuxThreads you can do this by spawning a thread and then comparing it's PID to the main thread's PID. If they differ it's LinuxThreads. You can then choose the best solution for the thread type.
If you are already polling your IO, another possible solution that is very simple is to just use a boolean to signal the other threads. A boolean is always either zero or not so there is no possibility of a partial update and a race condition. You can then just set this boolean flag without any mutexes that the other threads read. Tools like valgrind wont like it but in practice it works.
If you want to be even more correct you can use gcc's atomics but this is compiler specific.
I need a function(eg signal handler) in C/C++ linux that gets activated every 'n' milliseconds. How do I setup signals etc...to register to timer events at the millisecond resolution.
Accuracy is not super critical, but need within hundred ms or so.
I am new to linux and I really don't know where to start.
A much safer alternative to setitimer (which POSIX 2008 marks OBSolete) would be to use POSIX timers, and have the timer expiration function run in a thread rather than a signal handler. This way you are not restricted to only using async-signal-safe functions. They're documented here:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_05
If you don't like the POSIX timers API, you could instead create a thread that merely sleeps in a loop, and block the timer signal in all threads except that thread. Then you will be free to use whatever functions you like in the signal handler, since it will run in a separate thread and there is no danger of it interrupting an async-signal-unsafe function.
setitimer(2) is a good start, but do you really want to go asynchronous with signals? Otherwise, you could have a main loop with select(2) or poll(2) and an appropiate timeout.
I am creating a program with multiple threads using pthreads.
Is sleep() causing the process (all the threads) to stop executing or just the thread where I am calling sleep?
Just the thread. The POSIX documentation for sleep() says:
The sleep() function shall cause the calling thread to be suspended from execution...
Try this,
#include <unistd.h>
usleep(microseconds);
I usually use nanosleep and it works fine.
Nanosleep supends the execution of the calling thread. I have had the same doubt because in some man pages sleep refers to the entire process.
In practice, there are few cases where you just want to sleep for a small delay (milliseconds). For Linux, read time(7), and see also this answer. For a delay of more than a second, see sleep(3), for a small delay, see nanosleep(2). (A counter example might be a RasPerryPi running some embedded Linux and driving a robot; in such case you might indeed read from some hardware device every tenth of seconds). Of course what is sleeping is just a single kernel-scheduled task (so a process or thread).
It is likely that you want to code some event loop. In such a case, you probably want something like poll(2) or select(2), or you want to use condition variables (read a Pthread tutorial about pthread_cond_init etc...) associated with mutexes.
Threads are expensive resources (since each needs a call stack, often of a megabyte at least). You should prefer having one or a few event loops instead of having thousands of threads.
If you are coding for Linux, read also Advanced Linux Programming and syscalls(2) and pthreads(7).
Posix sleep function is not thread safe.
https://clang.llvm.org/extra/clang-tidy/checks/concurrency/mt-unsafe.html
sleep() function does not cease a specific thread, but it stops the whole process for the specified amount of time. For stopping the execution of a particular thread, we can use one pthread condition object and use pthread_cond_timedwait() function for making the thread wait for a specific amount of time. Each thread will have its own condition object and it will never receive a signal from any other thread.