tags:

views:

287

answers:

2

Follow up question to: This question

As described in the linked question, we have an API that uses an event look that polls select() to handle user defined callbacks.

I have a class using this like such:

class example{
 public:
    example(){
        Timer* theTimer1 =  Timer::Event::create(timeInterval,&example::FunctionName);
        Timer* theTimer2 =  Timer::Event::create(timeInterval,&example::FunctionName);
        start();
       cout<<pthread_self()<<endl;
    }
  private:
     void start(){
        while(true){
           if(condition)
              FunctionName();
           sleep(1);
        }
     }
     void FunctionName(){
         cout<<pthread_self()<<endl;
         //Do stuff
     }
};

The idea behind this is that you want FunctionName to be called both if the condition is true or when the timer is up. Not a complex concept. What I am wondering, is if FunctionName will be called both in the start() function and by the callback at the same time? This could cause some memory corruption for me, as they access a non-thread safe piece of shared memory.

My testing tells me that they do run in different threads (corruption only when I use the events), even though: cout<<pthread_self()<<endl; says they have the same thread id.

Can someone explains to me how these callbacks get forked off? What order do they get exectued? What thread do they run in? I assume they are running in the thread that does the select(), but then when do they get the same thread id?

+1  A: 

Your code as written won't compile, much less run. Example::FunctionName needs to be static, and needs to take an object reference to be used as a callback function.

If the timers run in separate threads, it's possible for this function to be called by three different threads.

Chris Kaminski
+3  A: 

The real answer would depend on the implementation of Timer, but if you're getting callbacks run from the same thread, it's most likely using signals or posix timers. Either way, select() isn't involved at all.

With signals and posix timers, there is very little you can do safely from the signal handler. Only certain specific signal safe calls, such as read() and write() (NOT fread() and fwrite(), or even new and cout) are allowed to be used. Typically what one will do is write() to a pipe or eventfd, then in another thread, or your main event loop running select(), notice this notification and handle it. This allows you to handle the signal in a safe manner.

bdonlan
You are right. Select is only there because the Event api handles select() events as well as Timers. >.< This appears to check the event times in a loop! (seperate thread)
windfinder
Incidentally, apis using signals are really rather painful to work with. Encourage whoever made it to run those callbacks as regular functions in a thread so they only have to take locks :)
bdonlan
For now I've just circumvented this with my own loop for the events. Obnoxious, I know, but at least I can properly make them thread safe...
windfinder