pascaldragon at googlemail.com
Fri Mar 23 15:41:12 CET 2012
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
>> - - 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
>> - 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.
More information about the Lazarus