Martin <[email protected]> hat am 27. Juni 2011 um 16:01 geschrieben: [...] > > > Think about "safely invoked" as no need for extra precautions to call it > > multi threaded, like e.g. critical sections or check which thread is > > running. > > Obviously "thread-safe" does not extend the safety nor does it fix any kind > > of flaw that is already there when called single threaded. > > And "thread safe" does not mean that calling a function multi threaded will > > give the same results as called single threaded. Although typically it > > does. > > > > And look up the definition of "function". A function is defined by the > > input, output and task. Failing means for some input the wrong output is > > returned. Input/Output are not only parameters. > > > Yes, but if I am correct, "input" for example can not (always) be limited to > the list of param (not even including hidden param, like self) > eg, a constructor, includes the task of allocating memory. If that fails a > defined behaviour should be expected (return nil, throw exception, ...). That > implies, that "available memory" in this case is part of the input. In fact a function's input can even be a file on disk. The memory manager is thread safe, so there is not much difference between single threaded and multi threaded here. > > Sure, similar flaws (with invalid data) can be constructed outside threads. > But the ability to store data in either a variable local to one thread, or > global to all threads does not exists without threads. Well, this depends on pov. So this is more a philosophical question. > > Yes the aim of the definition, is solely to extend the concept of being > called safely to being called safely from several threads. > But the above definition *limits* this requirement to "called at the same > time" English lacks the exactness of mathematical expressions. You are right, that the definition is not exact and the wikipedia page contains a few remarks about that. The nice thing about this definition is that everyone I knew instantly understands the idea and was able to apply it to most cases without much thinking, including methods and classes. Everyone - until I read this thread. Apparently some people have problems with it. Well, life is learning. > > > > > The "fail" depends on how you define the task of the function. > > I guess with "fail" you mean the function can fail its tasks when called > > multi threaded. Then it is by definition not thread safe. > > > > As I said, those examples, are not actually correct (for what I am > questioning) They only point into a direction. > > fail = not the result that is expected according to the definition of the > function (that could be: not return at all, crash, or return an incorrect > value as result...) Then the function is not thread safe. > > The example is merely to indicate, that thread related problems can occur, > even if calls are "not at the same time". True. And I would like to discuss this, but I'm not sure if this topic is Lazarus related. > [...] > > > > "At the same time" includes "subsequently", for the simple reason that > > critical sections are allowed, which simply turns a parallel (at the same > > time) into a sequential one. > > > There is a difference between called/invoked at the same time, and executed > at the same time. For "thread safe" it is the same. > > The original defintion says "invoked" they are still invoked at the same > time, even though *if* a critical section is used, the part inside it (and > only this part, not the whole piece of code, which includes the critical > section) is executed deferred. > > "at the same time" does not necessarily mean a critical section has to exist, > there are other means that allow for more parallel execution: > 2 read only calls, may not need to block each other at all. Yet a read-only > call may fail due to something thread related, that happened long before (in > an other thread, and only because it happened in an other thread). > > Yes. But then again it is a question of how you define the task of the code. Maybe you want this behavior, maybe you don't care. Mattias
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
