On 27/06/2011 11:58, Martin wrote:
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".
Make that "any defined/allowed" input
Obviously if you pass in a pointer to random memory as object instance
no function will be ave to call.
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".
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
