On Mon, Mar 3, 2014, at 05:32 PM, Michael Haberler wrote:
>
> moreover this aspect is completely irrelevant to the discussion topic at
> hand, which is about using scheduling behaviour used to assert certain
> properties of parallel programs
>
> can we focus on the actual problem please, which is _really_ fundamental -
> which is why I object to thread hijacking
>
The thread certainly has jumped around a bit, but I wouldn't call it
hijacking. I know for a fact that one of my earilest comments in this
thread was based on an unclear understanding of what Micheal
was getting at.
Seb's original posting in the thread said:
In the master branch, and in 2.5 and all earlier releases of LinuxCNC,
all HAL threads obey this invariant: short-period threads (ie, the base
thread) are never interrupted by longer-period threads (ie, the servo
thread).
The ubc branch changes the scheduling behavior of threads in the 'posix'
flavor, which is most similar to 'sim builds' in master and earlier.
The posix flavor does not match our invariant.
So, exactly what does posix do that is different?
I suspect that Michael, Charles, and others are concerned about what
happens on a multi-core system. And they probably should be - see
below. But what does posix do on a single core system? If, on a single
core system, a slower thread can interrupt (and therefore stop) a faster
thread, that is fundamentally broken. Atomic access has nothing to do
with it - it is simply a matter of latency and meeting real-time targets.
Can we agree that on a single core system, slow threads should never
steal the CPU from fast threads, and web browsers should never steal
the CPU from any "real-time" threads? Even if you are only doing
simulated real-time?
I hope we can agree on that, and if posix doesn't do the right thing
and we need "sudo make setuid" to get the proper priorities, then
we should do so.
With that behind us, it is time to look at multi-core systems, both
SMP and non-symmetrical (ARM+PRU). We also should consider
FPGA based systems, such as Mesa and Pico Systems. The FPGA
systems implement the "base thread" in hardware, and are really
nothing more than an extreme case of non-symmetrical multi-
processing.
Mesa and Pico systems manage to handle atomicity issues just
fine without ringbuffers or anything else. They were designed
such that the slow thread (on a CPU) can read or write any FPGA
register and the fast thread (running at 100MHz or so) will do the
right thing.
It would be foolish to try to implement a ringbuffer or other fairly
heavy-weight protocol in an FPGA. Instead, you define a register
map by which the slow task controls the fast hardware. Ideally
every register is independent and the FPGA does the right thing
regardless of what order you write them in.
In some cases, there may be groups of registers that need to be
atomic. It isn't uncommon to have double-buffers with a strobe
or similar signal that tells the FPGA to transfer from the first set
to the second set in parallel.
There are two kind of situations where signals cross a fast-slow
thread boundary. One is in something like a software stepgen,
OR an FPGA stepgen. A slow thread (driver code in the FPGA
case) is controlling a faster thread. The two pieces are designed
to work together - driver and FPGA, or "update_freq()" and
"make_pulses()". I would argue that the author of the module
or driver is the one who needs to make sure that interface works
correctly, and they should do it by careful design.
Although I brought up the "update_freq<--->make_pulses"
connection earlier in the thread, it was partly because I
wasn't sure of the intent of the discussion. To be honest,
I strongly suspect that that interface works much like the
CPU<--->FPGA register interface, and that the two
variables don't actually need to be processed atomically
at all. However, I'm not 100% sure without checking the
code. My intent was to say "if you are changing the
scheduling rules, you better check for side effects".
What Micheal and Charles are saying is "the rules changed
whether you like it or not, thanks to SMP and ARM/PRU".
All that means is that we do indeed need to check for
side effects. I bet we are actually in pretty good shape,
the original stepgen and encoder counters were designed
with a hardware model in mind and I think they are OK.
But they still need checked.
The other situation is where ordinary HAL signals are
written by a function in one thread and read by a function
in another thread. That situation isn't limited to two pieces
that were designed to work together. HAL users can
literally connect anything to anything. There may be
traps for the un-wary in that situation, but the vast majority
of such signals are atomic and really no problem. A
parport driver in the base thread has no problem
accepting spindle control signals from a slow thread,
or sending limit switch state to a slow thread.
--
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
