Mega Code Archive
Threads
<![CDATA[
THREADS
***********************************************************************************
http://www.delphizine.com/search/results.asp?QU=Threadmare&Method=E&limi
t=1&area=f
Two good articles on threads n such, they are probally more involved
than you would want but would give you a good idea of whats involved...
***********************************************************************************
RE: Feedback from long-running computation
> So, is there a simple solution to this? or do I have to learn about
> multithreading .. will it help if I put the compute intensive
> stuff in a
> separate thread?
>
Yes, putting it in a separate thread will work and it is very easy with
Delphi. Creating a thread is as simple as File|New|Thread. Now, you move
all of your code in to the thread's execute method (or create your own,
whatever you want) and then in your main program you create your thread and
then start it up.
MyThread := TMyThread.Create( TRUE );
MyThread.FreeOnTerminate := TRUE; { I like this option }
MyThread.Data := 0; {Set values here}
MyThread.Resume; {This starts it up}
In TMyThread you would have something like:
WHILE NOT(Terminated) AND (OtherCondition = FALSE) DO
BEGIN
{CIR - Assuming it loops until done}
END;
If you need notification on your main program when it's done, you could have
your thread call Synchronize( MyMethod ) where MyMethod calls something on
your main form, like showing a box, or turning off the clock animation, etc.
It's really not scary, give it a whirl. You may suddenly find all sorts of
applications for threads...just don't go crazy. *8)
If you have any questions about threads, feel free to post on the list or
ask me directly.
Todd Lang
***********************************************************************************
> Ray Lischner (I think) says that Tlists and
> Tstringlists are safe, which makes sense.
If you mean across threads then no they aren't. The way to determine if
something is thread safe is to workout if it access something (eg
variables/properties) using synchronisation methods
(Mutex/CriticalSection/etc...). If it doesn't then look out.
Now by thread safe we are talking about accessing something from multiple
thread. A TList, because it just maintains a list of pointers without regard to
who is accessing them is not safe. A TThreadList how ever is the same but with
the required mechanisms to ensure only one thread is accessing the list at one
time.
Now if your creating your own objects and need to have more than one thread
accessing them you need to implement a Criticalsection or Mutex etc.. when
accessing/modifying things in your object. A handy object to assist in this is
TMultiReadExclusiveWriteSynchronizer.
However, if you create an object in your thread, for use only by that thread,
then it doesn't need any of the above. The exception I think is visual objects,
like forms, as they need to be accessed by the main thread to receive messages.
The best way to handle using threads is to leave all visual stuff out, and only
perform background actions. E.g. It would be easy to say do a file search in a
thread, all the objects to handle the search would be created by the thread and
only the results posted in a Synchronised method as each match of the search is
found. Because the searching mechanisms are non-visual and only created/used in
the thread, it doesn't really matter if they are Thread safe, as no other thread
is going to access them anyway.
> There seems to be some divergence of opinion on the general use of
> synchronize .. on the one hand it is easy to use, on the other there is a
> possible performance hit .. well, I am finding my way here, and I
> appreciate the help.
If your calling synchronise all the time in your thread, it may actually perform
worse than a non-threaded solution, because your thread will actually stop
working until the main thread is ready to process the synchronised code. If for
instance you want to use synchronise to update the main form repeatable with a
progress bar, your losing all the benefit of threads. A better way is to post a
message back to the main thread with the current status, this way your thread is
still independent of the main thread.
Regards,
Anthony Richardson
anthony.richardson@sageautomation.com
anthony@viewpointsa.com
]]>