[Lazarus] Threads

[Antonio Fortuny]

Le 23/03/2012 12:18, Sven Barth a écrit :
> Am 23.03.2012 12:02, schrieb Michael Schnell:
>> Your concept of threads does not really hold.
>>
>> Regarding the thread object (TThread descendant) instance itself:
>>
>> It's creator is called by some thread (usually the project's main
>> thread) but of course not by the thread that is going to be created.
>>
>> Some of it's properties and functions are _supposed_ to be used by the
>> thread it owns (e.g. "Terminated")
>>
>> Some of it's properties and functions are _supposed_ to be used by other
>> threads (e.g. "Terminate")
>>
>> It depends on the user code what self-created additional functions and
>> properties are to be used by whom and if they can be considered to be
>> thread save.
>>
>> Same holds for stuff created outside of the thread unit, but supposed to
>> be used by the thread ("Execute" procedure).
>>
>> (There is no simplified concept.)
>
> You know that he wrote the following, stressing the part in the 
> parenthesis:
>
>> Assuming this few statements (aka my own rules when writing thread's 
>> code):
>
> Thus he is fully aware that this is not a general concept, but only 
> his own, "enforced" by himself.
That's the point. In fact I'm used to write thead code since a long time 
ago but without a formal guideline, only guessing what the OS is 
supposed to do and manage. This time I'm trying to describe in a more 
formal way the rules to follow, whose main purpose is to avoid problems 
since the very beginning. Basically you all three (Yourself, Michael and 
Dodi) have stated the same mechanisms which are the ones I guessed but 
not being sure they were correct. Now I'm a lot more confident on what 
is going on when multiple thread instances are running and this was the 
majoir point I wanted to focus on.
This will help me to figure out how things really happen  and to begin 
the drawing of an internal document stating how to write safe threads 
within the context of our company. Because Lazarus (Win & Linux, 32-64 
bit) is highly concerned, I posted my question in this thread (8-) ).

As a last conclusion all this leads me to prefer the writing of objects 
which will contain the thread functionality instead of writing internal 
thread methods. The big advantage is maintenance: it is easier when the 
code is spread over a series of specialized units which can focus on a 
particular side of the job (i.e. basic object used by the thread). 
Second advantage is the ability to use DUnit testing outside of the 
context of a thread. Another advantage is the possibility to reuse the 
objects code in other applications. I mean not specific thread code but 
general purpose code. As a mattrer of disadvantage I can point out the 
overhead introduced by the object internal code itself in terms of 
memory and process time. But it is immediately related to the base 
object itself. In any case, the former rules I've stated are still true.

Anyway, is seems clear to me that every thread code will be developed 
around ist particular concept and objectives. Michael is right too when 
he writes that there is no simplified concept.

Again, many thanks to all of you.

Antonio.


>
> Regards,
> Sven
>
> -- 
> _______________________________________________
> Lazarus mailing list
> Lazarus at lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>