[Lazarus] thread safe

[Martin]

On 27/06/2011 12:23, Michael Schnell wrote:
> On 06/27/2011 12:51 PM, Martin wrote:
>>
>> Why? Where does the definition conflict with the above?
>>   "A piece of code is *thread-safe* if it can be safely invoked by 
>> multiple threads at the same time"
> It does not *conflict* it is just not useful.
>
> The problem is not "safe invocation" the problem is "*a* piece of code".
>
> An object is invocated with a hidden self pointer. So for the "user" 
> this "self" is not an "input" as normal parameters are.

Unfortunately you left out the real important part of my last msg.

If you choose to ignore the full meaning of "safely invoked " (even 
WITHOUT threads), then I agree the definition is not useful. But then 
which definition is useful if you ignore parts of it?

Ask yourself: WITHOUT threads, when can a piece of code be "safely invoked"?
Answer: It can be safely invoked, if it will return a correct result for 
any input, within the range of input for which it is defined.

See my example about memory alloc in my other mail. It shows, that a 
piece of code (and it's ability to be "safely invoked ") does not solely 
depend on the parameters passed, but also on (selected parts of) the 
state of the application or system.



>
> By definition, an object is a combination of a data store and a pool 
> of functions.
The data part can be seen as "input", for the above definition
That this input is made available in a specific way does not matter.

But yes, It's your choice.

You can have an indefinite amount of definitions for each possible 
special case .
Or you can have one definition, using the most abstract common part of 
them all.

For the above it is enough to see an object as "a piece of code" (or 
several pieces of code), for (each of) which the data is a part of the 
input. It does not matter by which means this input is made available. 
It does not matter that the programmer does not need to explicitly 
specify this input.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110627/f8ae9c5f/attachment-0003.html>