🚀 go-pugleaf

Hi, Matt.

> I have a fairly large C++ Builder 6 project I would like to make threaded. 
> Apart from the main class which handles most of the UI, I have two other 
> major C++ classes that are just about pure C++ with no VCL. I would like to 
> convert these to threaded classes. This is a simulation of artificial life. 
> One of the classes is instantiated anything up to one hundred times [the 
> living animals] and the other up to three or four hundred [the food]. This 
> would mean I would have upwards of 500 threads, is this possibly under 
> Windows XP?
> 

500? I think it is possible but it makes no sense. Why must every object 
have it's own thread? Why not only a few (e.g. num of CPU's) threads who 
manage theses objects? Too many threads will loose a lot of time with OS 
switching between the threads.


> access. The way I intend to use them is have each thread start suspended and 
> use a timer on my main form to trigger the resuming of each thread. They go 
> off and do their thing, and suspend themselves when the work is done. The 
> next time the timer is activated it first checks the threads are all 
> suspended [i.e. they all finished doing their work last time round]. This is 
> the snag.

When the Execute() function of a TThread object is done, then the thread 
doesn't run anymore and can't run again without making a new instance of 
your thread object. Resume() and Suspend() make no sense on a thread 
which has left the Execute() function. If you don't wan't to make new 
instances of your threads every time, then you should apply a state 
machine in your thread where you can pause, run and exit your thread 
(everything has to be done in a loop in Execute()!). Resume() and 
Suspend() aren't suited for controlling running threads as you don't 
know the state of your thread when it suspends/resumes.

Hope this helps,

Oliver