On Fri, 10 Jun 2011 14:36:36 +0200 Michael Schnell <[email protected]> wrote:
> On 06/10/2011 02:18 PM, Mattias Gaertner wrote: > >> E.g. Regarding Objects this is not enough. > > Prove? > > Theory: with multiple instances, the same "piece of code" behaves > differently, according to to the states that are stored internally in an > instance. Not only theory. It's common practical thing. For example TThreadList.Add is thread safe and each call changes the object. > It's not practical to just ignore this as a specification: you now would > need to say that Objects never are thread safe and by this make any > object language totally unsuited for threaded application. I can't follow you here. > It's a lot more helpful to do a more sophisticated definition of > thread-safety for objects. > > > Example: > > Imagine you create an instance of an object for each thread. > > So the same "piece of code" (a function procedure or property of the > object) can behave differently regarding which instance is used (here > which thread is calling it). > > e.g. the function accesses just class variables (and local variables). > Now it is thread safe if in fact each thread uses it's instance; but > it's not thread safe, if a thread uses another thread's instance. I got the feeling you are not familiar with mathematical definitions. If the definition says "it can be safely invoked by multiple threads at the same time" then it means it can be invoked by any thread in any order at any time and the code still performs its task. For example: TThreadList.Add is thread safe because the task is to add an element to the list. If you define the task that after calling the element is in the list, then it would not be thread safe. > If it uses global variables it is not thread safe at all. No. For example the heap manager uses global variables and it is thread safe. Mattias -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
