Which is the better method? Allowing the thread to sleep for a while or deleting it and recreating it later?

Question

We have a process that needs to run every two hours. It's a process that needs to run on it's own thread so as to not interrupt normal processing.

When it runs, it will download 100k records and verify them against a DB. The framework to run this has a lot of objects managing this process. These objects only need to be around when the process is running.

What's a better standard?

Keep the thread in wait mode by letting it sleep until I need it again...

or...

Delete it when it is done and create it the next time I need it. (System Timer Events)

Answer 1

I think it's just a matter of taste. Both are good. Use the one which you find easier to implement. :)

Answer 2

I agree with Vilx that it's mostly a matter of taste. There is processing and memory overhead of both methods, but probably not enough for either to matter.

Answer 3

Starting one thread every two hours is very cheap, so I would go with that.

However, if there is a chance that at some time in the future the processing could take more than the run interval, you probably want to keep the thread alive. That way, you won't be creating a second thread that will start processing the records while the first is still running, possibly corrupting data or processing records twice.

Answer 4

If you are using Java you could check Timer class. It allows you to schedule tasks on given time.

Also, if you need more control you can use quartz library.

Answer 5

Either should be fine but I would lean towards keeping the thread around for cases where the verification takes longer than expected (ex: slow network links or slow database response).

Answer 6

I guess actually putting the thread to sleep is most effective, ending it and recreating it would "cost" some resources, while putting it to sleep would just fill a little space in the sceduler while it's data could be paged by the operationg system if needed.

But anyway it's probably not a very big difference, and the difference would probably depend on how good the OS' sceduler is, etc...

Answer 7

I would create the thread a single time, and use events/condition variables to let it sleep until signaled to wake up again. That way if the amount of time needed ever has to change, you only need change the timing in firing the event and your code will still be pretty clean.

Answer 8

There is not that much difference between the two solutions. I tend to prefer the one where the thread is created each time.

Having a thread lying around consumes resources (memory at least). In a garbage collected language, it may be easy to have some object retained in this thread, thus using even more memory. If you have not the thread laying around, all resources are freed and made available for two hours to the main process.

When you want to stop your whole process, where your thread may be executing or not, you need to interrupt the thread cleanly. It is always difficult to interrupt a thread or knowing if it is sleeping or working. You may have some race conditions there. Having the thread started on demand relieves you from those potential problems: you know if you started the thread and in that case calling thread_join makes you wait until the thread is done.

For those reasons, I would go for the thread on demand solution, even though the other one has no insurmontable problems.

Answer 9

How would you remember to start a new thread when the two hours are up ? With a timer? (That's on another thread!) with another thread that sleeps until the specified time? Shutting down the thread and restarting it based on something running somewhere else does you no good if the something else is either on it's own separate thread, or blocks the main app while it's waiting to "Create" the worker thread when the two hours are up, no?

Just let the Thread sleep...

Answer 10

It really depends on one thing as I can tell... state.

If the thread creates a lot of state (allocates memory) that is useful to have during the next iteration of the thread run, then I would keep it around. That way, your process can potentially optimize its run by only performing certain operations if certain things changed since the last running.

However, if the state that the process creates is significant compared with the amount of work to be done, and you are short on resources on the machine, then it may not be worth the cost of keeping the state around in between exectutions. If thats the case, then you should recreate the thread from scratch each time.

Answer 11

I wouldn't think it's very important, but the best approach is very platform dependent.

A .NET System.Threading.Timer costs nothing while it's waiting, and will invoke your code on a pool thread. In theory, that would be the best of both your suggestions.

Answer 12

Another important thing to consider if you are on a garbage collected system like Java is that anything strongly referenced by a sleeping thread is not garbage. In that respect, it's better to kill idle threads, and let them, and any objects they reference, get cleaned up.

Answer 13

It all depends, of course. But by default I would go with a separate process (not thread) started on demand.