Mattias Gaertner schrieb:
Whether a function is "thread safe" does not depend on how you call it. If a function can fail if it is called with wrong parameters or by the wrong Thread, then it is as Reimar wrote: it is not thread safe.
I dare to disagree. When a procedure call can fail in a single-threaded environment, for some reason, then it is allowed to fail in a multi-threaded environment as well. It's up to the function to return an appropriate error code - this doesn't make the procedure thread-unsafe.
And now follows a lot of text, how to safely call not thread safe functions, which might have been useful on a forum for parallel programming, if it would not invent misleading terms like "completely thread safe"
That's why I'd classify procedures as *immanently* thread-safe, when they don't rely on unsafe shared data (objects...), or as protected against *certain* threading issues. The rest will stay "unknown", or can have a list of *known* threading (or reentrancy...) issues.
Objects are much harder to classify, because only few of them are designed with only thread-safe public methods. Nonetheless it would be interesting to know, which objects (classes) can be used safely when *encapsulated* in an thread [created by the thread, no references passed to or ending up in other threads]. Obviously all event handlers and other notification callbacks, stored in an object, can violate this requirement.
DoDi -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
