[Lazarus] Synchronize problem in linux

[Zaher Dirkey]

On Wed, May 25, 2011 at 2:33 PM, <michael.vancanneyt at wisa.be> wrote:

>
>
> On Wed, 25 May 2011, Giuliano Colla wrote:
>
>  michael.vancanneyt at wisa.be ha scritto:
>>
>>>
>>>
>>> On Wed, 25 May 2011, Vincent Snijders wrote:
>>>
>>>  2011/5/25  <michael.vancanneyt at wisa.be>:
>>>>
>>>>> No. You should use a TMultiReadExclusiveWriteSynchronizer object to
>>>>>>> synchronize access to your object, or use a critical section.
>>>>>>>
>>>>>>
>>>>>> Ehm, he made sure that only one thread accesses the TStringList at a
>>>>>> time.
>>>>>>
>>>>>
>>>>> To me, this is not obvious from his mail ?
>>>>>
>>>>
>>>> I thought it was obvious from:
>>>> "The logic of the application itself made it sure that there was no
>>>> conflict whatsoever. "
>>>>
>>>> But maybe that was not not what Giuliano meant by "no conflict".
>>>>
>>>
>>> This is what was not clear to me...
>>>
>>> If no conflict can mean 'it adds only', then there is a conflict at a
>>> lower
>>> level, because adding can mean a reallocation of the array of strings.
>>>
>>>  The full picture is:
>> 1) The main thread creates the String List, and doesn't touch it any more.
>> 2) The other thread is activated and it is the only one which appends
>> strings to the list.
>> 3) When the other thread is terminated, the main thread processes the
>> list.
>>
>> I would expect that whatever activity occurs as an effect of appending
>> strings (such as reallocating the array) would occur in the context of the
>> thread performing the action, that all pertinent information is stored in
>> fields of the object itself, and that the main thread is never involved.  Am
>> I wrong on this aspect?
>>
>
> No, you are right. If it is designed as described above, then it should
> work.
>
> Michael.
>
>
But that mean he have only one thread worked at same time.

-- 
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110525/c7bce9dd/attachment-0003.html>