Am 23.03.2012 15:36, schrieb Antonio Fortuny:
Le 23/03/2012 15:24, Michael Schnell a écrit :
It's rather straight forward to do completely distinct threads.
The tricky part starts, when the threads need to communicate (which
always is necessary) and thus share some data.
Here you need to be aware of several things:
- the components and functions in the LCL and RTL usually are not
thread-save (and there is no documentation on in what way they are
"partly thread safe) e.g.
- - Many simple functions like IntToStr() seem to thread safe, but
this is not documented.
- - You can't use any function that accesses the GUI in another thread
but the main thread.
- - You can happily use multiple instances of TList in multiple
threads as long as each a single instance is not used by multiple
threads.
- - You can use the same instance of TList in multiple threads if you
use a TCtriticalSection (e.g. one for each instance of TList) do block
concurrent accesses.
- - AFAIK, the way TThreadList is used with multiple threads is
documented.
- To have a worker thread communicate with the main thread (i.e. to
have it use the GUI in any way) you can use TThread.Synchronize.
Downside: The thread waits until any scheduled main thread activity is
done before entering the synchronized code (might last forever). It
only goes on working when the synchronized code is done.
- To trigger a main thread activity without having to wait for the
main thread you can use Application.QueueAsnycCall.
- The functionality of TThread.Synchronize and
Application.QueuAsyncCall is not available in all Widget Types (see
Compile-Options -> Build Modes). It is verified to work decently in
GTK and Win32 (and supposedly QT, but I did not check this myself).
All those are the basics that I apply since I'm busy writing threads
code. I already make use of Critical sections and events lock some
external resources (log files for instance) and I avoid to have any
thread code using any kind of GUI. All thread code I write, is contained
in OS services or very specialized programs having no GUI at all.
Anyway, thanks for precisions.
Just for the case you understood that wrong: There is no pricincipal
problem of threads running in a GUI app. The problems arise only if you
access some visual component (e.g. change the Caption of a Label)
without using Synchronize. If you either use Synchronize or your threads
don't access the GUI directly, then you won't have problems with them.
E.g. the scanning of the Free Pascal source directory at the first start
of Lazarus (or when you change the source directory) is done using a thread.
Regards,
Sven
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
