Martin schrieb:
As stated in my former messages in this thread, IMHO, the "official"
definition of thread-safe-ness does not make much sense with objects,
but a more complex definition covering several cases of use is necessary.
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"
That's the definition of reentrant subroutines only.
"Save invocation" includes that the function returns a "correct"
result(output) for any "input".
Where "input":
- is not limited to the parameters passed in the parameter list, not
even to limited to parameters passed implicitly (such as the object
instance)
- input includes the entire state of the system (that can be global
vars, available and unavailable resources of any kind, and much more)
The same applies to "result", or "output".
This would mean that a thread-safe procedure has to lock *all* input
that it - or one of its called procedures - wants to read or update,
before starting at all. The best scenario for an unrecoverable deadlock :-(
This part of "Save invocation" is not limited to thread safeness. It
applies to any piece of code.
Your attempt to re-interpret above definition is of no use :-(
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
