I have a prog which has a lot of work to do and every now and again its needs some data from the disk. Disk I/O is of course slow buts theres usually plenty other things to be doing so I buffer up the opperations that need to be performed on the data and leave it to a thread to deal with the loading etc.
There are some constraints so I've had to hard code a limit on the number of threads which at any one time can be working away (currently 4). My question is theoretically is it better to kill the threads when they finish and spawn a new one later when needed, or should I have the threads spawn once and have them wait (using events and what not) till their needed.
I tried both but since disk acces is the bottleneck I can't compare on performance so I ask does anyone know if its cheaper (in terms of resources or whatever) to have a thread waiting or to create and destroy threads. In my current case I need the threads quite a bit (say 10,000+ times) so as it stands I've opting for waiting cause it feels like the other would be inefficient, but I don't know how to check for sure. Maybe someone here knows?
There are some constraints so I've had to hard code a limit on the number of threads which at any one time can be working away (currently 4). My question is theoretically is it better to kill the threads when they finish and spawn a new one later when needed, or should I have the threads spawn once and have them wait (using events and what not) till their needed.
I tried both but since disk acces is the bottleneck I can't compare on performance so I ask does anyone know if its cheaper (in terms of resources or whatever) to have a thread waiting or to create and destroy threads. In my current case I need the threads quite a bit (say 10,000+ times) so as it stands I've opting for waiting cause it feels like the other would be inefficient, but I don't know how to check for sure. Maybe someone here knows?
I would keep the threads waiting... there's overhead to creating+destroying threads, which while it might not be big, will be bigger than the one-time overhead of creating a few events.
Also, while a thread is waiting on an event (or in any other blocking state), it is removed from the ready-list and thus utilizing NO CPU time whatsoever - since it's removed from the ready-list, the scheduler doesn't have to check the list entry or anything.
This is one of the reasons why blocking is very efficient and polling should generally be avoided.
Also, while a thread is waiting on an event (or in any other blocking state), it is removed from the ready-list and thus utilizing NO CPU time whatsoever - since it's removed from the ready-list, the scheduler doesn't have to check the list entry or anything.
This is one of the reasons why blocking is very efficient and polling should generally be avoided.
Thanks f0dder, while it seemed like waiting was more sensible its good to have it explained better :) .
I guess there could be an advantage to destroy/create - you would detect resource leaks faster :P