On 27/06/2011 11:19, Michael Schnell wrote:
On 06/27/2011 11:37 AM, Martin wrote:
If the function, for example stores some important data in a thread
local variable, but flags (thread global) the availability of the
data, then no Critical section will fix it.
Yep !
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"
"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 part of "Save invocation" is not limited to thread safeness. It
applies to any piece of code.
For example, a piece of code involving memory allocation, must examine
the result of the actual "AllocMem" call for errors. Otherwhise it is
not save to be executed, as it may fail with an undefined result, if no
mem is available.
So as far as I can see, my example, (as well as objects) are very well
covered by the definition.
Martin
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
