On Tue, Mar 4, 2014, at 04:08 PM, Michael Haberler wrote:
> ok, let's move further. I feel we are converging on the following aspects:
>
> 1. a key issue is the atomic passing of multiple values between threads (all
> or none)
> 2. one way to ascertain this is the current method, which in effect makes one
> thread a critical region by making it non-preemptable by the other thread
> through means of higher priority *)
>
> I think the following is the key question (again this is correctness related
> only, performance is not relevant for the answer):
While the end result is the same, I think declaring
performance irrelevant is misleading.
I originally interpreted this thread as saying something like:
"Rate monotonic scheduling cannot guarantee atomicity in
todays SMP world, therefore we must do something else for
atomicity. (For example Pavel's ringbuffer code.)"
"Having solved atomicity some other way, rate-monotonic
scheduling is no longer needed, so we can drop it in posix."
I have no issue with the first sentence. However the last sentence is
wrong. In the original design, rate-monotonic scheduling was done
for performance reasons. It's atomicity benefits (on single core systems)
were strictly a side effect.
Rate-monotonic scheduling is STILL NEEDED for performance reasons.
It is not something that can simply be declared irrelevant. And every
variant (posix, RTAI, RT_PREEMPT, Xeno, etc) should provide rate-
monotonic scheduling. Atomicity has nothing to do with it.
I realise that I brought up atomicity myself with my first post about
communication between the parts of stepgen. At that time I wasn't
clear about what the goal of the discussion was.
> The answer is directly relevant for this: can non-conventional
> thread setups like coprocessors not coordinated by the OS
> (ala PRU, DSP etc) be used in the future or not.
This is the core of the discussion. Rate-monotonicity is irrelevant.
It cannot guarantee atomicity when RT code is running on more
than one core, or when the "base thread" is running on a PRU
or FPGA. So lets agree to stop talking about scheduling and
start talking about how to achieve atomic transfers with these
new architectures.
> encoder.c and stepgen.c should be made to perform correctly
> in face of arbitrary thread priorities and thread preemption.
Yes, of course.
> I think this is relatively little effort in terms of code. The result
> must certainly reviewed thoroughly under the new baseline
> assumptions, but it is not rocket science either. **)
The existing code must first be reviewed thoroughly under
the new baseline. As mentioned earlier, a side effect of
rate-monotonic scheduling was that it became a little easier
to do the atomic stuff needed in stepgen. So now, we need
to make sure the code no longer relies on un-preemptability.
We may find that little or nothing needs to be done.
I started to review stepgen for a reply to this thread, but my
employer would rather I spend my working hours on work.
(They are funny that way.) I saw enough in that quick look
to tell that would be educational to review the code on-list.
I believe only tiny tweaks will be needed for stepgen.
Certainly nothing like adding ringbuffers. I have a busy
evening tonight, and work tomorrow, but I hope to post
the analysis of stepgen.c tomorrow evening.
> Do we have any other candidate components which are
> affected by such revised assumptions? I'm not aware of
> any right away.
Stepgen, pwmgen, and encoder are the ones I can think of
right now.
--
John Kasunich
[email protected]
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
