CODEWITHSUNDEEP
operating-systemreal-timethreadx
Justin
Justin

Reputation: 35

What aspects of ThreadX make it a realtime OS?

ThreadX is considered a RTOS. I know general definitions and requirements of an RTOS, however, could anyone help to shed some light on why ThreadX can be called an RTOS, or, what features of the OS make it realtime capable?

Thanks~

Upvotes: 2

Views: 5279

Answers (4)

Andrés
Andrés

Reputation: 51

ThreadX will have the same response time no matter the size of the system: if the system has one thread or many, one semaphore or many, etc the response time will be the same. All operations have constant response times. Thread preemption time is bounded and constant. Interrupt response time is bounded and constant. The level of capabilities that ThreadX offers is sometimes described in academic literature as "hard real-time".

Upvotes: 0

Darshan Rajgor
Darshan Rajgor

Reputation: 21

Not an expert but, When you impose time constraints on application threads/processes it is called real-time software.

In RTOS, if high priority thread comes then low priority thread will be suspended until high priority thread is finished (or go into to idle/suspended state). Low priority thread will never get time (event time slice is enabled) until any high priority thread is active.

In case of same thread priority, if time slice is enabled then each thread will get specific amount of time.

You should also check priority inversion in RTOS case.

Upvotes: 0

VictorEE
VictorEE

Reputation: 91

When programmers talk about real-time operating systems they often mention features that relate to managing multiple processes or threads: mutexes, semaphores and interprocess (or interthread) communications etc.

However the true definition is that the system must guarantee that some given operations will always happen within a known, deterministic time (i.e. time in seconds, not in relative terms). Neither Linux or Windows are truly real time. A Linux or Windows computer can be so blazing fast that whatever you want done will almost always happen fast enough - but there is no guarantee that it will always be within a maximum time. If you are building a software system to control a medical device or a huge piece of factory equipment, then you need to stop or start something in x-milliseconds, not "soon", or "usually fast enough".

Now in practice, to provide this guarantee in a useful, non-trivial system one often needs pre-emptive multitasking, multiple threads and all the features usually mentioned, so you would be hard pressed to find an RTOS without them. However, the defining characteristic of an RTOS is right in the name: things can be known to happen in a real amount of time.

As to your specific question, from the ThreadX web site:

ThreadX is deteriminstic. A high priority thread starts responding to 
an external event on the order of the time it takes to perform a 
highly optimized ThreadX context switch.

    - Boot time: 300 cycles
    - Context switch time: <100 cycles
    - Semaphore get: 30 cycles

Upvotes: 3

Tereus Scott
Tereus Scott

Reputation: 682

What it all means is that your response time is deterministic. This is one of the most important things you want in an RTOS.

In threadx your threads have a priority. The operating system is driven by a hardware interrupt timer and the scheduler ensures that the threads are scheduled correctly according to their priority.

For example, if thread A (high priority) is waiting on a semaphore and thread B (low priority) is running, then as as soon as the semaphore becomes available then thread B will be interrupted and thread A will be started.

Threadx has a number of other features to optimize the context switching time. For example, each thread has its own stack.

For more detail you should get this: http://www.amazon.com/Real-Time-Embedded-Multithreading-Using-ThreadX/dp/1578201349/ref=sr_1_2?s=books&ie=UTF8&qid=1390859108&sr=1-2&keywords=real+time+threadx

Upvotes: 0

Related Questions