Re: DataObjectLockFree: fix facts in doxygen

On Wed, Dec 12, 2012 at 1:07 PM, Sébastien Barthélémy
<[email protected]> wrote:
>
>
> On Tue, Dec 11, 2012 at 3:46 PM, Peter Soetens <[email protected]>
> wrote:
>>
>> Which should imo read:
>>
>> +     *
>> +     * The internal buffer will get full if more concurrent threads
>> than max_threads
>> +     * are accessing this object. In such a case, the read occurs
>> anyway and late
>> +     * readers can get corrupted values.
>
>
>
> I misread the return at line 210 for a break. So with this new reading, I
> think
> data corruption cannot occur if the buffer gets full: new readers will get
> an old value, but it won't be corrupted.
>
> So please do not consider my previous patch but instead the two attached to
> this email.
>
> The first one fixes the doxygen regarding the single writer thing.
>
> The second improves the comments (up to my understanding), especially
> regarding the race condition.
>
> Regarding the way this race condition is dealt with (in the loop at line
> 170), if I got it right, a reader thread can get delayed if a write occurs
> while it is between lines 171 and 172: it has to spin the loop again (it
> kinds of polls the buffer).
>
> If this happens repetitively the reader might be delayed forever. Even if
> the writer has lower priority.
>
> I agree that this would be an occurrence of "very high frequency systematic
> bad luck", but still, is not that lack of determinism a concern?
>
> I have no great solution to propose. Replacing
>
> reading != read_ptr
>
> with
>
> reading != write_ptr
>
> would reduce the probability of occurrence, at the price of a loss of some
> freshness.
>
>
> Hopefully, I got it wrong, or some pre-condition I'm not aware of ensures
> Murphy cannot win in this case.

Please stop quoting data corruption in your patches. We have setup
extreme unit tests testing any combination of concurrent reads and
writes for hours on multi-core machines and this algorithm will never
corrupt your data. Also checkout the RTT unit tests which have never
found a bug in this very algorithm with multiple threads/cores.
A write might fail (ie result in a nop) if you don't respect the
max_threads, that's it.

Peter
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev