On Fri, 17 Sep 2010, Stuart Glaser wrote:
> Hi,
>
> On Fri, Sep 17, 2010 at 12:53 PM, Konrad Banachowicz <konradb3@gmail.com> wrote:
>> yes RT and non-RT work execute in separated threads but what about shared
>> data ? as far as i know there is some locking involved ?
>
> The buffer used in the JointSplineTrajectoryController is called a
> RealtimeBox.
That's an unfortunate naming...: "realtime" is not an absolute property of
an object, or a buffer, or an algorithm, but of the system configuration in
which it is being used.
> It currently uses a mutex (locked for a guaranteed
> maximum number of instructions on a system that supports priority
> inheritance), though it can certainly switch to a lock-free buffer.
>
>> Communication between RT and non-RT threads is complex problem, but OROCOS
>> solves most problems. it use lock-free buffers for communication between
>> components.
It _can_ use them, but need not. They should be used with care, that is,
only when you are _very_ sure that one component must really be _THE_ hard
realtime component. Because the implementation is trading-off latency for
that single component with overall throughput.
> Currently in ROS joint_trajectory_action is whole non-RT and
>> JointSplineTrajectoryControlle is partialy RT. In my solution all non-RT
>> work are moved into joint_trajectory_action. This make clear border between
>> RT and non-RT part.
>
> Sounds like you've moved the non-realtime parts of the
> JointSplineTrajectoryController into your version of the
> joint_trajectory_action. That sounds like a reasonable solution.
It is reasonable indeed!
Herman
(text/plain)