1

Is it a good idea to design a real time system on a multicore processor? Task's execution time isn't determinist in these kind of processor because of core management. This makes scheduler's elaboration hard to do.

M.Ferru
  • 3,926
  • 3
  • 22
  • 48
  • Depends on how you define "multicore". It is possible for each core to have isolated state information. – Ignacio Vazquez-Abrams Apr 03 '17 at 12:47
  • Do you mean that a certain task isn't "share" by all the core but executed by only one? – M.Ferru Apr 03 '17 at 12:55
  • It also depends on how you define "real time". How hard are your deadlines, and how much uncertainty does core scheduling actually introduce? – Dave Tweed Apr 03 '17 at 12:55
  • 3
    When I've developed with multi core processor (LPC4350) for real time, each core had its own application, they just shared memory and peripherals. Each was still real time. – Colin Apr 03 '17 at 12:58
  • I asked this question by pure curiosity, I have no real exemple at the moment. Let suppose that deadline are hard (the task have to be done before the dead line) – M.Ferru Apr 03 '17 at 12:58
  • Task execution time is not completely deterministic on a single core either, unless you disable all interrupts except the timer. – Dmitry Grigoryev Apr 03 '17 at 12:59
  • @Colin__s So tasks are not share to all the core? Execution time is then determinist and it's possible to make a decent scheduler – M.Ferru Apr 03 '17 at 13:01
  • @DmitryGrigoryev Are you sure? When a interruption occur, tasks are preempted, it doesn't affect execution time. Right? – M.Ferru Apr 03 '17 at 13:03
  • 1
    I have a feeling that we're talking past each other. Why do you think that preemption doesn't affect the ability of a task to meet its deadline? – Dave Tweed Apr 03 '17 at 13:07
  • @M.Ferru That will depend on the hardware you use, the embedded processor I worked with it was easy to define which software ran on which core, there was no scheduler involved. – Colin Apr 03 '17 at 13:09
  • @DaveTweed Preemption is mandatory for a real time system to make every task meets its deadline. If the overall load is correctly calculate, every tasks should meet its deadline. What I don't understand is that since execution isn't determinist in a multicore processor (am I right?), how is it possible to know the total load and be sure that the system will work fine? – M.Ferru Apr 03 '17 at 13:24
  • No, you're not right. Execution time is just as deterministic on a core in a multicore chip as it is on a single-core chip. Or are you talking about reductions in throughput that are due to conflicts that occur when accessing shared resources such as memory? That isn't a scheduling issue, but you do need to apply a fudge factor to the core's execution speed. – Dave Tweed Apr 03 '17 at 13:28
  • This is why I was confuse. In multi core processor, a part of the processor is used to manage cores. I thought that makes the execution time impossible to know accurately. – M.Ferru Apr 03 '17 at 13:33
  • if you need examples, search for "xmos", whose each physical core running at 400MHz is time-sliced into 8 50MHz logical cores and can have as many as 4 physical cores. Their design philosophy is not only to provide each task with a core, but also to use core to implement peripherals like PWMs and timers, because there are so may of them. – user3528438 Apr 03 '17 at 14:01

2 Answers2

2

When designing multitasking real-time systems, you assign each task a priority that allows it to meet its deadline, keeping in mind that it may be preempted by any higher-priority tasks. If you have N cores, then the N highest-priority tasks will never need to be preempted, and will always meet their deadlines.

I hope this addresses your hypothetical question; if not, please clarify what you want, and I'll expand my answer.

Dave Tweed
  • 168,369
  • 17
  • 228
  • 393
  • From a core perspective I would agree, but from an uncore perspective, if you don't have the hardware to support isoch, you have no guarantee that a low priority core's traffic couldn't negatively interfere with the higher priority core's traffic in the uncore. Even IIO could greatly interfere with core traffic resulting in delays that can't be accounted for from the core perspective. To me it's all about the hardware architecture I guess. – horta Apr 04 '17 at 12:49
  • @horta: You're using jargon that I don't understand. What are "uncore", "isoch" and "IIO"? But in any case, if access to shared resources such as memory or I/O becomes a bottleneck, then the chip is not adequate for the application, period. The number of cores becomes irrelevant, and this is not an argument against using multiple cores *per se*. – Dave Tweed Apr 04 '17 at 12:58
  • Uncore is pretty much everything outside of the core. Isoch, short for isochronous traffic, is a guaranteed latency amount for a type of traffic. It's typically used for things like audio to prevent your music from crackling and popping while you do other things on your computer. IIO is peripherals that come in from agents like the PCH (platform controller hub) or PCIE that could overwhelm the cache or memory subsystem. I guess I'm saying that multiple cores can interfere with each other at a system level. If you don't use multiple cores, you may never reach the limits of the I/O or memory. – horta Apr 04 '17 at 14:45
  • @horta: OK, well, you're throwing in a lot of *implementation details* related to a particular system architecture -- one that's more relevant to desktop systems than to embedded systems anyway. The OP's question is much more generic than that, and I provided a similarly generic answer. – Dave Tweed Apr 04 '17 at 15:01
  • Yup, I understand. A generic question can't really be answered well. – horta Apr 04 '17 at 15:13
2

It really depends on the application.

I think however what you are describing is a multi-threaded controller. Where programs are sequenced to one or more processors under the control of some background OS. Multi-thread, like your PC, can result in VERY wide variation in response time.

A multi-core processor is simpler than that, but does need to share access to memory and peripherals and does have a inherent potential lag.

If you have a system that requires a response within a few clock cycles or the thing will fail catastrophically, then using a threaded/multi-core controller is not going to suffice.

If on the other hand, it is ok to wait a few mS to respond, and the known worst case controller reaction delay is kept beneath that number, then it will work as intended.

Bottom line is, if the control system is time sensitive, use multi-threading and multi-core with care.

Where necessary, offload such time sensitive tasks to dedicated processors or systems and circuits and use the multi controller as a supervisor.

Trevor_G
  • 46,364
  • 8
  • 68
  • 151