Link to home
Create AccountLog in
Avatar of learningunix
learningunix

asked on

sleeping

I am looking to release resources and wake up every 30 secs and do some process.

Here's what I do:

is this the efficient way to do or can I simply do?

while (1)
{
   sleep(30);
   // do something
}

mutex_lock(myLock);

time_t vTime = ::time(NULL);
struct timespec myTime;
myTime.tv_sec = vTime + 30; // 30 secs more than current time
myTime.tv_nsec = 0;

cond_timedwait(&myCond, &myMutex, &myTime);  // This will sleep for 30 secs and then wakeup

// fo watever you want. 

mutex_unlock(myLock);

Open in new window

ASKER CERTIFIED SOLUTION
Avatar of jkr
jkr
Flag of Germany image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
Avatar of phoffric
phoffric

If you must sleep for 30 seconds, then sleep. The myTime in cond_timedwait() is not a forced sleep for 30 seconds; but rather a timeout. You are guaranteed that you will not remain on the cond_timedwait for more than 30 seconds, but you may remain there very briefly if another thread immediately signals the condition after you hit that line. So, the semantics of sleep and the myTime timeout are very different.


I noticed that you have
>>  mutex_lock(myLock);
>>  cond_timedwait(&myCond, &myMutex, &myTime);  

From http://uw714doc.sco.com/en/man/html.3synch/cond_timedwait.3synch.html

"int cond_timedwait(cond_t *cond, mutex_t *mutex, timestruc_t *abstime);

The calling thread must lock the mutual exclusion lock (mutex) pointed to by mutex before calling cond_timedwait, otherwise the behavior is unpredictable."
But you are locking with myLock and then using myMutex instead of myLock.

If you need a condition variable to meet your design goals, then you have to use it (carefully), and you may as well wait. If you can avoid condition variables, I would do so as they are one of the more difficult aspects of concurrent control.
I didn't see jkr's post when I submitted my post. At first it appeared that we were saying different things about equivalency. But after a little thinking, I realized that perhaps you were never planning on having another thread send a condition signal thereby forcing a timeout in order to get the effect of a simple sleep. If that is the case, then I wouldn't clutter up your code with this extra threading control. As already noted, the condition variable is a little harder to get right than other thread functions.

Also, re: sleep - From http://linux.die.net/man/3/sleep
sleep() makes the current process sleep until seconds seconds have elapsed or a signal arrives which is not ignored .

Return Value
Zero if the requested time has elapsed, or the number of seconds left to sleep.
Avatar of learningunix

ASKER

its only accessed by single thread so that is not an issue.
I guess sleep() would be better in my case as threads would be overhead?
while (1)
{
   sleep(30);
   // do something
}

ensure you have a condition to break out from the while loop....else as per your design above the thread could sleep forever
>>I guess sleep() would be better in my case as threads would be overhead?

Definitely - even if you could live with the overhead, since that probably is negligible nowadays. But, *clean* programming does not depend on the power of the hardware you have at your purpose.
SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
thx