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@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
