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.

On the contrary ! This is the whole reason of using lock-free loops
instead of mutexes: if the writer has lower priority, it won't preampt
the read and the read returns immediately. If the writer has higher
priority, the writer returns immediately. It's always the higher
priority thread which is favoured, and never the lower priority
thread. Indeed, the lower priority thread can starve, but that's your
architecture doing that, not my algorithm.

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

It's 100% deterministic for the highest priority thread contending on this data.

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

He can't. We left nothing to the coincidence.

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