CODEWITHSUNDEEP
cmultithreadingfunctiontimer
user2586678
user2586678

Reputation: 11

Call a function periodically within a thread in C

I'm writing a program in C which connects to a camcorder via wifi and can control zoom, start and stop recording when the user wants to execute these functions.

After the initial connect to the camcorder, I will have to send a Session Refresh Command every 5 seconds. So my idea was to start a new thread after the initial connect which sends the refresh command every 5 seconds.Something like,

while(1) {
    sendRefreshCommand(); 
    usleep(5000000); 
}

Is this idea ok, or is there any other way to achieve that?

Edit: Here is my code so far to illustrate a little bit what I want to do. The user is permanently asked what he wants to do. This is for testing purposes only. Later on the zoom and recording commands will be performed by the program automatically. Parallel to asking the user the session has to be refreshed every 5 seconds.

#include <stdio.h>
#include <unistd.h>
#include <pthread.h>
#include "camctrl.h"

extern struct conf  g_Config;

void* sessionContinueThread(void *session_args){
    while(1){
        sessionContinue(g_Config.cam_ip);
        usleep(3000000);
    }
}

int main(){
int         sel;
pthread_t   session_thread;
void        *arg2;

readConfig("config2.json");

ConnectToCam(g_Config.cam_ip);

arg2 = (void *) g_Config.cam_ip;
pthread_create( &session_thread , NULL , sessionContinueThread , arg2 );
pthread_join(session_thread,NULL);

while(1){
    printf("\n[0] Zoom Tele\n");
    printf("[1] Zoom Wide\n");
    printf("[2] Start Recording\n");
    printf("[3] Stop Recording\n");
    printf("[4] Session Continue\n");
    printf("[5]Stop\n");
    printf("Selection: ");
    scanf("%d",&sel);

    switch( sel ){
        case 0: zoomTele(); break;
        case 1: zoomWide(); break;
        case 2: RecStart(); break;
        case 3: RecStop(); break;
        case 4: sessionContinue(g_Config.cam_ip); break;
        case 5: exit(0); break;
        default: break;
    }
}
return 0;
}

Upvotes: 1

Views: 2051

Answers (2)

junix
junix

Reputation: 3211

Generally this is OK. But there are some considerations you should think about:

  1. You have to synchronize the access to your transmission channel in order to not get some very weird, hard to trace and reproduce effects
  2. Don't set the timeout for the refresh command exactly to 5s, take e.g. the half or a few percent lower than 5s. Otherwise you'll possibly suffer from effects that arise from jitter. (e.g. if the timebase of your camcorder is about as accurate as the timebase of your PC, the camcorder will get the "keep alive" message after 5s + transmission time if you send the request after 5s. This would be a timeout then.
  3. Think about introducing a gate keeper thread or object to serialize the access to your communication channel. This would give you some opportunities to optimize. For example, I could imagine, that you don't have to send the keep-alive if you just issued a command.
  4. Don't start the thread with while(1). Hand the thread a reference to a value or an event object that allows you to signal the thread it should be terminated. This gives you the opportunity to clean up everything properly when shutting down your program.

If you want me to explain some of the considerations further, let me know.

EDIT: Further explaination to #4: You should take care that you clean up every resource you allocate. Of course you can rely on the OS that it's possibly cleaning up threads and stuff when it throws your process out of the memory, but that's not really a good way to go. So after you creating your thread and running your program, you should also destroy your thread when the program will exit. To do so you can of course invoke some calls that terminate the thread immediately. The downside of that is, that you can happen to leave some things (e.g. mutexes) in undefined state.

What does this mean? Imagine the thread took the mutex, was about to send something and exactly at that point in time your main thread terminates the thread. In this case your mutex might remain locked, and everyone else is unable to aquire it. (e.g. to send a session destroy command).

So the solution to avoid such things is to request the thread to terminate rather than forcing the termination from outside. The request leaves the thread the chance to cleanup things he possibly allocated or acquired and then exit. The thread requesting the other thread to terminate should wait for the other thread before exiting himself (using kind of a join function).

Upvotes: 1

Chinna
Chinna

Reputation: 3992

Your idea is looking good. You can achieve same by using alarm signal and signal handlers. Initialize a signal handler for alarm signal and rise alarm signal by passing 5 as argument. After 5 seconds your process receives a sigalarm signal and it invokes signal handler of sigalrm. In signal handler send refresh command and again raise sigalrm for 5 seconds. This loops continuously works. But thing is your main program execution is halted every time it receives a sigalrm

Upvotes: 0

Related Questions