[Lazarus] thread safe (concurrently versus subsequently)

[Mattias Gaertner]

 Martin <lazarus at mfriebe.de> hat am 27. Juni 2011 um 16:01 geschrieben:
 [...]
> 
> > 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.
> > 

>  Yes, but if I am correct, "input" for example can not (always) be limited to
> the list of param (not even including hidden param, like self)
>  eg, a constructor, includes the task of allocating memory. If that fails a
> defined behaviour should be expected (return nil, throw exception, ...). That
> implies, that "available memory" in this case is part of the input.
In fact a function's input can even be a file on disk. 
The memory manager is thread safe, so there is not much difference between
single threaded and multi threaded here. 
 
 


> 
>  Sure, similar flaws (with invalid data) can be constructed outside threads.
> But the ability to store data in either a variable local to one thread, or
> global to all threads does not exists without threads.
Well, this depends on pov. So this is more a philosophical question. 
 


> 
>  Yes the aim of the definition, is solely to extend the concept of being
> called safely to being called safely from several threads.
>  But the above definition *limits* this requirement to "called at the same
> time"
English lacks the exactness of mathematical expressions.  
You are right, that the definition is not exact and the wikipedia page contains
a few remarks about that.
The nice thing about this definition is that everyone I knew instantly
understands the idea and was able to apply it to most cases without much
thinking, including methods and classes. Everyone - until I read this thread.
Apparently some people have problems with it. Well, life is learning. 
 
 


> 
> > 
> > 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.
> > 

> 
>  As I said, those examples, are not actually correct (for what I am
> questioning) They only point into a direction.
> 
>  fail = not the result that is expected according to the definition of the
> function (that could be: not return at all, crash, or return an incorrect
> value as result...)
 
Then the function is not thread safe. 
 


> 
>  The example is merely to indicate, that thread related problems can occur,
> even if calls are "not at the same time".
True.  
And I would like to discuss this, but I'm not sure if this topic is Lazarus
related. 

 


>  [...]
> > 
> > "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.
> > 

>  There is a difference between called/invoked at the same time, and executed
> at the same time.
For "thread safe" it is the same. 
 
 


> 
>  The original defintion says "invoked" they are still invoked at the same
> time, even though *if* a critical section is used, the part inside it (and
> only this part, not the whole piece of code, which includes the critical
> section) is executed deferred.
> 
>  "at the same time" does not necessarily mean a critical section has to exist,
> there are other means that allow for more parallel execution:
>   2 read only calls, may not need to block each other at all. Yet a read-only 
> call may fail due to something thread related, that happened long before (in
> an other thread, and only because it happened in an other thread).
> 
> 
Yes. But then again it is a question of how you define the task of the code.
Maybe you want this behavior, maybe you don't care. 
 
 
Mattias
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110627/15af3d4f/attachment-0003.html>