[Lazarus] thread safe

[Mattias Gaertner]

On Fri, 10 Jun 2011 14:36:36 +0200
Michael Schnell <mschnell at lumino.de> 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