----- Original Message -----
From: "gajo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 15, 2004 9:00 AM
Subject: Re: [DUG] Should I use threads? I need suggestions how
tosolvethisproblem!
> As for the threading solution, I have looked into it, but found this in
the
> Help file:
>
> Warning: Do not create too many threads in your application. The overhead
in
> managing multiple threads can impact performance. The recommended limit is
> 16 threads per process on single processor systems. This limit assumes
that
> most of those threads are waiting for external events. If all threads are
> active, you will want to use fewer.
>
>
> Does this mean I cannot create more than 16 instances of the same thread,
or
> that I cannot create more than 16 thread classes?
Gajo,
the threading issue pretty much comes down to common sense. There seems
to be little penalty in creating a large number of threads of the same class
or different classes if they are all going to be blocked by some kind of
external event and allowed to wake up again in an orderly fashion such that
only a few are ever going to be executing at any given moment.
I have a program that uses > 100 threads suimultaneously to talk to remote
databases with no performance problems. The important bit is that each
thread does something, then waits (for a couple of minutes) until it can
begome active again 'coz the remote database takes that long to respond.
Effectively the processor usage on all of these threads is zero until the
thing that wakes them up actually happens.
Programming anything to use multiple threads effectively is much harder
than the documentation makes out, so you should avoid separate threads until
you have also figured out how to use the various synchronization objects
that the OS provides to keep them under control. One of the easiest things
to do when writing a multi-threaded program is to build in race conditions
where a worker thread is waiting for the VCL thread which is also waiting
for the worker thread. This is called a deadlock and is considered to be a
BAD THING. Calling Synchronize in the wrong place is a good way of doing
this, as is calling MyThread.WaitFor
To move the objects around on your screen (and having them in a
TObjectList is a good idea) you probably just need a timer and a
TimerExpired method returning a boolean.. Then (with a fast timer) it would
be easy to write:
procedure TMyForm.TimerTimer(Sender : TObject);
var
i : integer;
begin
for i := 0 to MyList.count -1 do
if TMoveable(MyList[i]).TimerExpired then
TMoveable(MyList[i]).Move;
end
The TimerExpired method could call GetTickCount and compare it with the
target time. The move method would update the target time. I am assuming
that each TMoveable already knows where to move to next and how to do that.
You will also run into problems if you remove objects from the list while
the list iterator (the for loop) is running. A simple solution (when an
object goes off the screen) is to post a message back to the form saying
that you wish to die. Since this will be handled asynchronously, it is
reasonably safe.
eg
const WM_DIE = WM_USER;
PostMessage(MainForm.Handle, wm_DIE, 0, integer(self));
procedure TMyForm.WM_Die(var Msg:TMessage)
var
i : integer;
begin
i := MyList.IndexOfObject(TObject(Msg.lParam));
if i >= 0 then
MyList.Delete(i);
// assumes MyList.OwnsObjects = true
end
Another silly word of warning, if you post WM_TIMER messages to your main
form, be sure not to set lParam to anything but nul or 0. WM_TIMER messages
are handled slightly differently from most in that if you set the lParam to
anything other than 0, then windows will just jump into your code using the
lParam as the execution address. It can be funny.
HTH
Trevor
_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi
