• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 384
  • Last Modified:

signal

This is in reference to
http://www.experts-exchange.com/Programming/Languages/CPP/Q_26884790.html#a35129837

I think so this can happen:

While control in thread is executing sleep(30), Now my main program executes
cond_signal(&myWait);

At this point there is no one to wait on condition variable?

wouldn't the signal call be lost and it will never print the line "I was called by cleanUp. Exiting now"
void cleanUp() {
     cond_signal(&myWait);
     join(&thread);
}


void myLoop() { 
  while (1)
  {
      .....
      mutex_lock(&myMutex);   

      cond_timedwait(&myWait, &myMutex, &myTime);  //myTime will be current time + 60 secs
If (status != 0)  // it timed out and I continue the execution
       {
             //  continue the execution
             sleep (30);   
             //  continue the execution
        }
       else 
         {
            printf ("I was called by cleanUp. Exiting now");     
            break;
         }
  }
     mutex_unlock(&myMutex )
}

Open in new window

0
learningunix
Asked:
learningunix
  • 3
  • 2
  • 2
2 Solutions
 
jkrCommented:
Um, yes - if you call 'cond_signal()' while the thread is inside 'sleep()', the signal would indeed be lost.
0
 
learningunixAuthor Commented:
That's what I was saying in previous thread ;)  that means the solution in my previous thread won't work

I used sleep() just as an example but if it is not sleep() and executing some other other time consuming commands, will it still be lost?

0
 
learningunixAuthor Commented:
or I'll have to design is such a way that situation like this should not occur
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
jkrCommented:
Yes, while you are not explicitly waiting for such a signal, it would go unnoticed. For such a case, astandard POSIX signal (http://en.wikipedia.org/wiki/Signal.h) might be the better choice.
0
 
sarabandeCommented:
if the myWait was already signaled when you call the cond_timdwait it will return immediately with 0.

so if you continue after sleep in the loop a call of cond_signal was not be lost.

but you need to move the mutex_lock before the loop cause the mutex was reestablished by cond_timedwait before return. so while sleeping the lock is still active and you don't need a new lock with next loop cycle.
 
Sara
0
 
sarabandeCommented:
for a gently termination of a worker thread by main thread cond_timedwait is a bit of overkill. especially if you have sleep of 30 seconds where no check was done.

if you would pass a pointer to the thread which simply could be asked whether to terminate or not you could much simpler do the job.

// some header
class ThreadControl
{
    volatile bool stop;
    ThreadControl() : stop(false) {}
    void stopThread() { stop = true; }
    bool isStopped() { return stop; }
};

// main thread:

  ThreadControl * ptc = new ThreadControl();
  pthread_create(...., ptc);

  ....
  ptc->stopThread();
  join(&thread);

// worker thread:

void threadfunc(void* p)
{
    ThreadControl * ptc = (ThreadControl *)p;    

    ...
        // do as often as possible:
        if (ptc->isStopped())
            return;

}

Open in new window


the point is that the cond_ functions have the main purpose to immdiately restart a waiting thread. but in your scenario you mostly have a running thread which occasionally has a waiting period. so you can't expect that the thread immediately will end but you can narrow the recognition time period to the time the longest call would need where you can't pass the ptc into.

Sara
0
 
learningunixAuthor Commented:
thx
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now