[Lazarus] thread safe (concurrently versus subsequently)

[Martin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110627/4b28501e/attachment-0003.html>