Can priority based scheduling achieve thread(task) concurrency in a single core CPU?

Question

I am confused about whether a priority based tasks within one process can achieve concurrency on a single core CPU.

My understanding about concurrency is threads of processes logically parallel, which means these execution flows can start, run, and complete in overlapping time periods. Quoting

However, the method to achieve thread concurrency in a single core CPU from most books or information online I collected is to using Round-robin, in which the OS scheduler give time slice for each tasks(threads).

In automotive AUTOSAR RTOS, usually only one process running on each CPU and the tasks are scheduled according to their pre-configured priorities (static). In single core CPU case, it is obviously impossible to achieve task concurrency if the tasks are non-preemptive, but what if the tasks are configured as preemptive?

For example, task A, B exists on one CPU with priority A > B, task B runs first and then B is preempted by task A, A finished after a while then B continue the reset of its codes. **Does task A and B concurrent during these period? ** I think it is, if not, can or how the priority-based scheduling achieve thread concurrency in a single process on single core CPU?

I search on Google but failed to find expected answers, thanks， hope someone help clear my confusion :)

Answer 1

It's all down to the operating system. RTOSes like VxWorks will happily preemptively schedule tasks (a.k.a. threads) of different priority on a single CPU on a first come first served basis, with time slicing for equal priority tasks.

The fact that it is given 1 CPU makes no difference to whether or not the system can meet it's real time requirements; so long as there's enough compute power to get all the work done in time, real time requirements are often about latency of response. That's generally about the context switch time and the time taken to go from an interrupt being raised (an external event which must be responded to) to the task that'll handle it running. That latency is more dependent on interrupt handling architectures in the CPU, rather than how many cores it has got.

The task will then take some time to handle the interrupt, and if the task is itself a single thread then again, the number of CPU cores need be no more than 1.

Other RTOSes like INTEGRITY, you pre-allocate runtime to process spaces, and the process will get (for example) 33% of total run time. If you give it 3 processes, each with 33% of runtime, then each will get 1 in 3 timeslices on a round robin basis (regardless of whether or not the other processes actually need all of the time in their time slice). INTEGRITY in fact was (maybe still is?) a single core OS - it'd actively ignore multiple cores, largely because of security design goal the creators set themselves in building INTEGRITY. AUTOSAR RTOS sounds slightly similar. What's happening is that the OS is using a timer chip to raise interrupts regularly, and using that to decide which Process should run next (regardless of any interrupts, preemption, whatever, needed inside a process to schedule threads). In INTEGRITY, a high priority thread in a process will get preempted by another process, if its process has had it's share of time slices.

Desktop OSes will all happily schedule threads.