[Lazarus] thread safe (concurrently versus subsequently)

[Mattias Gaertner]

 Martin <lazarus at mfriebe.de> hat am 27. Juni 2011 um 14:47 geschrieben:


>  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"
 
Think about "safely invoked" as no need for extra precautions to call it multi
threaded, like e.g. critical sections or check which thread is running. 
Obviously "thread-safe" does not extend the safety nor does it fix any kind of
flaw that is already there when called single threaded. 
And "thread safe" does not mean that calling a function multi threaded will give
the same results as called single threaded. Although typically it does. 
 
And look up the definition of "function". A function is defined by the input,
output and task. Failing means for some input the wrong output is returned.
Input/Output are not only parameters. 
 
 


> 
>  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.
 
The "fail" depends on how you define the task of the function.
I guess with "fail" you mean the function can fail its tasks when called multi
threaded. Then it is by definition not thread safe.
 
 


>  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"
 
"At the same time" includes "subsequently", for the simple reason that critical
sections are allowed, which simply turns a parallel (at the same time) into a
sequential one. 
 
 


>  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" ?


 Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110627/d90389fc/attachment-0003.html>