[Lazarus] thread safe (concurrently versus subsequently)

Martin lazarus at mfriebe.de
Mon Jun 27 16:01:49 CEST 2011


On 27/06/2011 14:23, Mattias Gaertner 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.
>

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.

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.

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"


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

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

The example is merely to indicate, that thread related problems can 
occur, even if calls are "not at the same time".

Yes similar issues can be constructed without threads. But without 
threads you do not have a differentiation between data accessible to 
just one thread, and data accessible to all threads. So problems arising 
from this, are thread related.

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

There is a difference between called/invoked at the same time, and 
executed at the same time.

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

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


More information about the Lazarus mailing list