Hello, I am developing a program in c++ and I have to implement a cron. This cron should be executed every hour and every 24 hours for different reasons. My first idea was to make an independent pthread and sleep it during 1h every time. Is this correct? I mean, is really efficient to have a thread asleep more than awake? What are the inconvenients of having a thread slept?
+4
A:
I would tend to prefer to have such a task running via cron/scheduler since it is to run at pre-determined intervals, as opposed to in response to some environmental event. So the program should just 'do' what ever it needs to do, and then be executed by the operating system as needed. This also makes it easy to change the frequency of execution - just change the scheduling, rather than needing to rebuild the app or expose extra configurability.
That said, if you really, really wanted to do it that way, you probably would not sleep for the whole hour; You would sleep in multiple of some smaller time frame (perhaps five minutes, or what ever seems appropriate) and have a variable keeping the 'last run' time so you know when to run again.
Sleep() calls typically won't be exceptionally accurate as far as the time the thread ends up sleeping; it depends on what other threads have tasks waiting, etc.
Andrew Barber
2010-09-20 11:13:06
Should I use pthread sleep or just sleep from unistd.h?
JoniPichoni
2010-09-20 11:43:27
+2
A:
My first idea was to make an independent pthread and sleep it during 1h every time.
I see no problem.
Is this correct? I mean, is really efficient to have a thread asleep more than awake?
As long as a thread sleeps and doesn't wake up, OS wouldn't even bother with its existence.
Though otherwise, if thread sleeps most of its life, why to have a dedicated thread? Why other thread (e.g. main thread) can't check the time, and start a thread to do the cron job?
What are the inconvenients of having a thread slept?
None. But the fact that the sleeping thread cannot be easily unblocked. That is a concern if one needs proper shutdown of an application. That is why it is a better idea to have another (busy) thread to check the time and start the cron job when needed.
Dummy00001
2010-09-20 11:15:54
AFAIK [`pthread.h`](http://www.opengroup.org/onlinepubs/000095399/basedefs/pthread.h.html) doesn't have its own sleep. For longer sleeps I would definitely recommend `sleep()`. Better alternatives like `clock_nanosleep()` and `nanosleep()` are still have portability problems regarding how long one can sleep with them (e.g. on some HP-UXs `nanosleep()` can't sleep longer than ~2-3 seconds). You can try first `clock_nanosleep()`/`nanosleep()`, if that will not work for you, then use the `sleep()`.
Dummy00001
2010-09-20 12:27:32
+3
A:
There is no performance impact of having a thread sleeping for a long time, aside of the fact that it will occupy some memory without doing anything useful. Maybe if you'd do it for thousands of threads there would be some slow down in the OS's management of threads, but it doesn't look like you are planning to do that.
A practical disadvantage of having a thread sleep for long is, that you can't do anything with it. If you, for example, want to tell the thread that it should stop because the application wants to shut down, the thread could only get this message after the sleep. So your application either needs a very long time to shut down, or the thread will need to be stopped forcefully.
sth
2010-09-20 11:36:12
+1. Should have it wait, on a condition variable for example. http://en.wikipedia.org/wiki/Monitor_(synchronization)#Blocking_condition_variables
sje397
2010-09-20 12:29:31
Good point. Shutdown of an application is often disregarded. I personally prefer to do all stuff (when possible) in one thread and implement some primitive timer service (e.g. `std::map< time_t, job * >`) and instead of plain sleeping one anyway has to `poll()` for external events. (And signals *conveniently* interrupt the `poll()`.)
Dummy00001
2010-09-20 12:36:41
+1
A:
When designing your solution keep these scenarios in mind:
- At 07:03 the system time is reset to 06:59. What happens one minute later?
- At 07:03 the system time is moved forward to 07:59. What happens one minute later?
- At 07:59 the system time is moved forward to 08:01. Is the 08:00-job ever executed?
The answers to those questions will tell you a lot about how you should implement your solution.
The performance of the solution should not be an issue. A single sleeping thread will use minimal resources.
Rasmus Faber
2010-09-20 12:19:56
IME change of time in such manner is strictly forbidden on production systems. Otherwise, that is another vote for dumb `sleep()` ( or more intelligent `pthread_cond_timed_wait()`) because it doesn't rely on absolute time - but the relative time instead.
Dummy00001
2010-09-20 12:42:26