On 10/06/2011 12:26, Henry Vermaak wrote:
On 10/06/11 02:09, Hans-Peter Diettrich wrote:
What is "thread safe"?
The definition is very clear here:
http://en.wikipedia.org/wiki/Thread_safety
"A piece of code is *thread-safe* if it can be safely invoked by
multiple threads at the same time"
Just to point out first, I am aware of the discussion this has already
sparked, and in the light of any argument of that discussion, in my
opinion this definition is correct.
Yet I came to think of a case, for which I wonder, and would like to
hear opinions, if indeed the above statement is complete.
My query is about the part: "at the same time"
Now a piece of code could for example mix up thread local and thread
global data:
- cache access to thread local data in a thread global way. Subsequent
calls from another thread may fail.
- create an initialize some data, and store it thread-local, while
flagging it's existence thread global. Subsequent calls from another
thread may fail.
Even if such code was using some sort of locking (mutex,
criticalsection, ...) it would fail. It would not need to be executed
from several threads "at the same time", it fails if executed by several
threads subsequently.
However so far of course each of those would also fail, if called "at
the same time". So all my examples are indeed covered by the original
definition.
The question is, is it prooven, or can it be prooven, that no code can
be constructed, that would "not fail if called at the same time", but
that would fail if called "subsequently"
That would be code, for which *during* its execution the application
would be in a state valid to enter the code in another thread, but
*after* it's execution, this validity would no longer be given.
If such code can be constructed, then would the above statement have to
be extended to "subsequent calls of the piece of code" ?
Martin
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
