🚀 go-pugleaf

Hi Matt,

>>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.
> 
> 
> This is a conversion of an existing application which has many instances of 
> these two classes. As they have quite a bit of code in each to handle 
> behaviour I could not think of any other logical way of threading each so 
> they run independently of each other.
> 

I don't know your code, but 500 threads working on their Execute() 
functions aren't faster than 500 times running "EstablishBehaviour" on 
your objects sequently.


> 
> 
> My Execute function is running a loop already that repeats 
> EstablishBehaviour followed by Suspend. My main class then uses a timer to 
> Resume them so the EstablishBehaviour is run again. The Execute function is 
> not ended until the simulation is terminated or the application exited. Here 
> is the actual code:
> 

O.K. then you should google for "TThread::Suspended not reliable?", 
maybe that's your problem. As mentioned here before I would work with 
events to control the thread and I wouldn't use Resume()/Suspend() 
anymore, with one exception: I would always create the threads suspended 
and resume them on the end of the constructor. Why? If you create a 
thread non-suspended then the Execute() function may run before your 
constructor has run. And then you're probably working with unitialized 
member vars in the Execute() function and you'll get some nice effects ;-)

Bye, Oliver