[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] DataObjectLockFree: fix facts in doxygen
From:       barthelemy () crans ! org (=?ISO-8859-1?Q?S=E9bastien_Barth=E9l=E9my?=)
Date:       2012-12-12 13:59:32
Message-ID: CAPkDDd7hmYgFvROdNpx0qBzaOcjbwNbusH42FfHBG4-ku6Q-Pw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Dec 12, 2012 at 2:14 PM, Peter Soetens <peter at thesourceworks.com>wrote:

> On Wed, Dec 12, 2012 at 1:07 PM, S?bastien Barth?l?my
> <barthelemy at crans.org> wrote:
> > 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


I was thinking of the two threads running concurrently on a multi-core
machine a reader and a writer. Hence one does not preempt the other.

In such a case, the low priority reader can get (very) slightly delayed by
the write since it may have to copy read_ptr again. And again if another
write at the wrong time again.

I guess this repetition just does not show up in practice. The reader has
enough time to poll the read_ptr while the writer is writing.

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.
> 
> [...]
> 
> Please stop quoting data corruption in your patches.


Agreed, as said in the previous mail, I do not suspect data corruption any
more.

My second doxygen patch held a few lines from the previous version
apparently. Sorry for the mess. Here is a third one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mech.kuleuven.be/pipermail/orocos-dev/attachments/20121212/7ba1c19a/attachment-0001.html \
                
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-DataObjectLockFree-fix-doxygen.patch
Type: application/octet-stream
Size: 2766 bytes
Desc: not available
Url : http://lists.mech.kuleuven.be/pipermail/orocos-dev/attachments/20121212/7ba1c19a/attachment-0002.obj \
                
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-DataObjectLockFree-improve-comments.patch
Type: application/octet-stream
Size: 3397 bytes
Desc: not available
Url : http://lists.mech.kuleuven.be/pipermail/orocos-dev/attachments/20121212/7ba1c19a/attachment-0003.obj \



[prev in list] [next in list] [prev in thread] [next in thread]