I'm working on a application that has specific timing restraints such that an event should occur (ideally exactly) every 200us. I'm trying to do this with a timer and signal.
#include <stdio.h>
#include <time.h>
#include <signal.h>
#include <unistd.h>
#include <pthread.h>
timer_t timer_id;
void start_timer(void)
{
struct itimerspec value;
value.it_value.tv_sec = 0;
value.it_value.tv_nsec = 20000;
value.it_interval.tv_sec = 0;
value.it_interval.tv_nsec = 200000;
timer_create(CLOCK_REALTIME, NULL, &timer_id);
timer_settime(timer_id, 0, &value, NULL);
}
void handler(int sig) {
printf("in handler\n");
}
void *my_thread(void *ignore)
{
(void)ignore;
start_timer();
// Sleep forever
while(1) sleep(1000);
}
int main()
{
pthread_t thread_id;
(void) signal(SIGALRM, handler);
pthread_create(&thread_id, NULL, my_thread, NULL);
// sleep is a placeholder for this SO question. I want to do
// other processing here
sleep(5000);
printf("sleep finished\n");
}
After 200us the signal handler is called. It appears to be called when the sleep(5000) line is running because the "sleep finished" message is displayed early. I want the timer to disrupt the thread that started the timer, not the main process. This is why I created a thread to start it. Is there a way to have the signal only abort the current instruction on the thread instead of on the main process? I know that the other threads/processes will be blocked when the handler runs, but I wanted them to continue afterwards as if nothing happened. For example, in this case I want to sleep at least 5000 seconds.
Yes, you can block the signal (pthread_sigmask) in the main thread before starting any other threads, and only unblock it in the thread intended to handle it. This will ensure that it arrives in the thread you want it in.
However, if you already have threads, are you sure you actually need a timer generating a signal for this? clock_nanosleep should allow sleep with wakeup at a precise time, and avoids all the awfulness of signals.
Related
I want to call timer_handler function at every 2 seconds regardless of execution time of timer_handler function here is my code
#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/time.h>
void timer_handler (int signum)
{
static int count = 0;
sleep(1);
printf ("timer expired %d times %d signum \n", ++count, signum);
}
int main ()
{
struct sigaction sa;
struct itimerval timer;
/* timer_handler as the signal handler for SIGVTALRM. */
memset (&sa, 0, sizeof (sa));
sa.sa_handler = &timer_handler;
sigaction (SIGVTALRM, &sa, NULL);
/* Configure the timer to expire after 2000 msec... */
timer.it_value.tv_sec = 2;
timer.it_value.tv_usec = 0;
/* ... and every 2000 msec after that. */
timer.it_interval.tv_sec = 2;
timer.it_interval.tv_usec = 0;
/* Start a virtual timer. It counts down whenever this process is
executing. */
setitimer (ITIMER_VIRTUAL, &timer, NULL);
/* Do busy work. */
while (1);
}
As per above code it should print timer expired 1 times 26 signum at every two second but its prints on every 3 seconds which includes sleep time so i want to call that function on every 2 seconds.
I don't know where i am doing wrong
If any other library is able to do this please let me know
Thank you
Why not use wall-clock time?
To do so
install the signal handler for SIGALRM instead of SIGVTALRM and
specify ITIMER_REAL instead of ITIMER_VIRTUAL.
Unrelated but important: Signal handlers may only call async-signal-safe functions. printf() is not one of those. For a list of the latter click here and scroll down.
the call, in the signal handler: sleep(1) is adding an extra second to the processing of the signal. This extra second is not part of the execution time of the process.
remove from the signal handler:
sleep(1);
regarding:
setitimer (ITIMER_VIRTUAL, &timer, NULL);
since you want to see the signal handler executed every 2 seconds, the proper timer to use is: ITIMER_REAL not ITIMER_VIRTUAL. This will result in the 'clock on the wall' time being measured rather than the 'process run' time being measured.
Strongly suggest having the signal handler ONLY set a flag. Then the 'do nothing' loop in the main function be checking that flag, reset the flag, then call printf()` To properly accomplish this, with out an 'race' conditions, use a mutex/ Both the main and the signal handler would lock the mutex, modify the flag, then unlock the mutex.
I am building a pre-emptive userspace thread scheduler which uses a timer to interrupt threads and switch between them according to priority. However, once a thread is interrupted, I cannot seem to let it finish; only start it again. Is what I am asking for even possible using swapcontext? The result of this code, which should allow itake5seconds() to complete, just loops the "Hello" message over and over.
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>
#include <ucontext.h>
static ucontext_t mainc, newthread;
void itake5seconds()
{
puts("Hello. I take 5 seconds to run.");
sleep(5);
puts("And I'm done! Wasn't that nice?");
}
void timer_handler(int signum)
{
puts("Doing some scheduler stuff.");
swapcontext(&mainc, &newthread);
}
int main(int argc, char* argv[])
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_handler = &timer_handler;
sigaction(SIGALRM, &sa, NULL);
getcontext(&newthread);
newthread.uc_stack.ss_sp = malloc(5000);
newthread.uc_stack.ss_size = 5000;
newthread.uc_link = &mainc;
makecontext(&newthread, &itake5seconds, 0);
struct itimerval timer;
timer.it_value.tv_sec = 0;
timer.it_value.tv_usec = 500000;
timer.it_interval.tv_sec = 0;
timer.it_interval.tv_usec = 500000;
setitimer(ITIMER_REAL, &timer, NULL);
while(1);
return 0;
}
Your code is calling an "unsafe" function in the signal handler (swapcontext). Therefor, the behavior of your program is "undefined".
From man 7 signal:
A signal handler function must be very careful, since processing elsewhere may be interrupted at some arbitrary point in the execution of the program. POSIX has the concept of "safe function". If a signal interrupts the execution of an unsafe function, and handler calls an unsafe function, then the behavior of the program is undefined.
See the "Example for SVID Context Handling" section in Complete Context Control for an example of how you can work this with a signal handler. But basically you'd use a volatile int global variable to flag that your signal handler was called and instead do the swapcontext call from normal code (i.e. code that's not running from within the context of signal handling).
The problem was that I was not saving the current execution context that swapcontext() returns to its first parameter.
I am not sure I understand semaphores and threads so I decided to try a relatively simple example. I am trying to have 2 threads that will alternate printing, one printing "ping" the other printing "pong" each notifying the other that it is done by use of a semaphore. But when I implement the code below, it prints ping several hundred times followed by pong several hundred times with a slight pause.
#include <semaphore.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
sem_t pingsem;
void ping(){
printf("Ping started\n");
while(1){
sem_wait(&pingsem);
printf("ping\n");
sem_post(&pingsem);
}
}
void pong(){
printf("Pong started\n");
while(1){
sem_wait(&pingsem);
printf("pong\n");
sleep(1);
sem_post(&pingsem);
}
}
int main(){
sem_destroy(&pingsem); //make sure the semaphore starts dead
sem_init(&pingsem, 0, 1); //initialize semaphore
pthread_t ping_thread, pong_thread; //start the threading
pthread_create(&ping_thread, NULL, ping, NULL);
pthread_create(&pong_thread, NULL, pong, NULL);
pthread_join(ping_thread,NULL);
pthread_join(pong_thread,NULL);
return 0;
}
I compile using:
gcc stest.c -o stest -lpthread -lrt
with no errors or warnings, but when I run it I get:
$ ./stest
Ping started
ping
ping
ping
ping
Pong started
ping
ping
.
. hundreds of pings
.
ping
ping
ping
pong
pong
pong
pong
.
. hundreds of pongs
.
It will eventually switch off but why are the threads not alternating printing every other one?
The problem shown in your example is, it's a race because neither read effectively blocks the other. Both threads run as the scheduler allows. The way it's coded, each thread can free-run (loop) multiple times during its time slice, and satisfies its own semaphore test. On a multi-core/multi-CPU system with a typical schedule, both threads can both run simultaneously and step all over each other somewhat arbitrarily.
Here's a working ping-ponging threads example that uses complimentary semaphores to create the ping-pong interlock you want.
#include <semaphore.h>
#include <pthread.h>
#include <stdio.h>
sem_t pingsem, pongsem;
void *
ping(void *arg)
{
for (;;) {
sem_wait(&pingsem);
printf("ping\n");
sem_post(&pongsem);
}
}
void *
pong(void *arg)
{
for (;;) {
sem_wait(&pongsem);
printf("pong\n");
sem_post(&pingsem);
}
}
int
main(void)
{
sem_init(&pingsem, 0, 0);
sem_init(&pongsem, 0, 1);
pthread_t ping_thread, pong_thread;
pthread_create(&ping_thread, NULL, ping, NULL);
pthread_create(&pong_thread, NULL, pong, NULL);
pthread_join(ping_thread, NULL);
pthread_join(pong_thread, NULL);
return 0;
}
Because when you create a thread it will execute as soon as the OS says it can!
So you created two threads like so:
pthread_create(&ping_thread, NULL, ping, NULL);
// scheduler interrupt from OS
pthread_create(&pong_thread, NULL, pong, NULL);
Which was fine, but the OS saw the first new thread and ran it until its timeslice was exhausted. Only then did the main thread get back control long enough to create the next thread.
As for why they're not alternating is a different issue! You see how difficult thread synchronization can be? You have this code:
while(1){
sem_wait(&pingsem);
printf("ping\n");
sem_post(&pingsem);
}
But you initialized the semaphore to the value of 1. So sem_wait decrements to 0, then prints a message, then increments back to 1. No problem, right?
Well the delay between the sem_post and the subsequent(next loop) sem_wait is only 1 instruction, a jump back to the beginning of the loop. So unless, by chance, the OS interrupts the thread after the sem_post, but before the sem_wait, the single thread will continue printing on its own.
You need two semaphores, 'pingsem' and 'pongsem', say. Initialize one to 1 and the other to zero. Then:
ping_thread:
while(true){
wait(pingsem);
doWork();
send(pongsem);
}
pong_thread:
while(true){
wait(pongsem);
doWork();
send(pingsem);
}
The one unit that was initialized into one semaphore then acts as a work token and is signaled back-and-forth between the threads. Only the thread with the token can do the work, the other has to wait until it gets the token.
James T. Smith has the right answer.. that since you didn't schedule out before grabbing your lock again, you would expect just about every time it would be able to re-grab the lock before the thread finished it's time slice.
If you want to force scheduling out so that the other one can run, you can try sleep(0) or sched_yield(). This will force a scheduling out so that if another thread was waiting to run it would. This would be more likely to see your ping,pong,ping,pong. But still not a guarantee and completely dependent on your OS scheduler (and probably only works on a single core system with both threads at the same priority).
Try this: (like I said.. no guarantees.. but a good possibility it will work)
void ping(){
printf("Ping started\n");
while(1){
sem_wait(&pingsem);
printf("ping\n");
sem_post(&pingsem);
sched_yield(); // Schedule out.
}
}
void pong(){
printf("Pong started\n");
while(1){
sem_wait(&pingsem);
printf("pong\n");
sleep(1);
sem_post(&pingsem);
sched_yield(); // Schedule out.
}
}
edit: changed to sched_yield()
The other answers are correct, I'm just posting code that will run as you desire (on OSX 10.10.3 anyway)
#include <semaphore.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
sem_t pingsem;
void ping(){
printf("Ping started\n");
while (1) {
sem_wait(&pingsem);
printf("ping\n");
sem_post(&pingsem);
}
}
void pong(){
printf("Pong started\n");
while (1) {
sem_wait(&pingsem);
printf("pong\n");
sem_post(&pingsem);
}
}
int main(){
sem_destroy(&pingsem); //make sure the semaphore starts dead
sem_init(&pingsem, 0, 1); //initialize semaphore
pthread_t ping_thread, pong_thread; //start the threading
pthread_create(&ping_thread, NULL, ping, (void *)0);
pthread_create(&pong_thread, NULL, pong, (void *)1);
pthread_exit(NULL);
return 0;
}
#include <stdio.h>
#include <pthread.h>
#include <signal.h>
sigset_t set;
int sigint_signal = 0;
pthread_t monitor_thread, demo_thread;
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
void *monitor()
{
while(1)
{
sigwait(&set, NULL);
pthread_mutex_lock(&m);
printf("__SIGINT received__\n");
sigint_signal = 1;
pthread_cancel(demo_thread);
pthread_mutex_unlock(&m);
}
}
void *demo_function(){
while(1){
pthread_mutex_lock(&m);
fprintf(stdout, "__Value of SIGNAL FLAG %d:__\n",sigint_signal);
pthread_mutex_unlock(&m);
}
return NULL;
}
int main(){
sigemptyset(&set);
sigaddset(&set,SIGINT);
pthread_sigmask(SIG_BLOCK,&set,0);
pthread_create(&monitor_thread, 0, monitor, NULL);
pthread_create(&demo_thread, 0, demo_function, NULL);
pthread_join(demo_thread, NULL);
return 0;
}
monitor_thread is the thread that is continuously running to catch the SIGINT signal. On receiving the signal it must cancel the other thread and end.
SIGINT is getting received, this can be verified with the value of the variable sigint_signal which becomes 1 once the signal is received.But pthread_cancel is not getting executed, because once the value of sigint_signal is changed to 1, the demo_thread keeps on running.Please help.
Read the documentation: http://man7.org/linux/man-pages/man3/pthread_cancel.3.html
There you will see that pthread_cancel is not guaranteed to instantly kill the thread, but rather that it depends on the state of that thread. By default, cancellation can only occur at cancellation points, which do include write() which may indirectly include printf().
Anyway, the real solution is to not use pthread_cancel at all, and instead use sigint_signal as the while loop condition in demo_function.
As for why pthread_cancel is a bad idea, this is because in general, functions are usually not written in a way that they are prepared to die. It's hard to reason about resource management in a context where execution might be terminated asynchronously.
Revisiting this question:
I have multiple threads running (pthreads api), each with it's own timer that calls a function handler(int signum) after a certain interval. As these threads call handler and within the function handler, how do I know which thread called it? Is thread-specific data required?
I notice that the thread that enters the handler function is a different thread from the one that set it up, so calling pthread_self() doesn't work. How do I get around this?
Here is a small example illustrating the problem
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <time.h>
#include <unistd.h>
void handler(int);
void call_alarm();
void *setup(void*);
pthread_t p;
void handler(int signum)
{
printf("handler thread %lu\n", pthread_self());
}
void call_alarm()
{
static struct itimerval timer;
static struct sigaction sa;
printf("call_alarm %lu\n", (unsigned long)pthread_self());
sa.sa_handler = handler;
sa.sa_flags = SA_RESETHAND;
timer.it_value.tv_usec = 500;
timer.it_value.tv_sec = 0;
timer.it_interval.tv_sec = 0;
timer.it_interval.tv_usec = 0;
sigaction(SIGALRM, &sa, 0);
setitimer(ITIMER_REAL, &timer, 0);
}
void *setup(void *param)
{
while(1)
{
printf("caller thread %lu\n", pthread_self());
call_alarm();
pause();
}
}
int main(void)
{
if(pthread_create(&p, NULL, setup, NULL));
while(1);
return 0;
}
Output:
caller thread 3086637968
call_alarm 3086637968
handler thread 3086640832
As you can see it prints out different values.
You can print the thread ID when the handler is called:
On Linux: gettid()
On Windows GetCurrentThreadId().
and if you can't, write a function wrapper around the handler and tell your code to call the wrapper function instead of calling the handler directly.
The POSIX chapter on Signal Generation and Delivery states:
At the time of generation, a determination shall be made whether the signal has been generated for the process or for a specific thread within the process. Signals which are generated by some action attributable to a particular thread, such as a hardware fault, shall be generated for the thread that caused the signal to be generated. Signals that are generated in association with a process ID or process group ID or an asynchronous event, such as terminal activity, shall be generated for the process.
I wonder if the SIGALRM signal you're catching is not considered a action attributable to a particular thread, such as a hardware fault. It sounds like your SIGALRM signal falls into the second category, and is being generated for the process.