2

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~

Fiddling Bits
  • 8,712
  • 3
  • 28
  • 46
Justin
  • 35
  • 1
  • 7
  • See http://en.wikipedia.org/wiki/ThreadX – E. Douglas Jensen Jul 03 '12 at 00:45
  • Thanks for the pointer, however, it says in the wiki: **Like most RTOSes, ThreadX uses a multitasking kernel with preemptive scheduling, fast interrupt response, memory management, interthread communication, mutual exclusion, event notification, and thread synchronization features.** which is too ambiguous and some of the features can also be found in many general OS's. Could you please share some more in detail? – Justin Jul 05 '12 at 13:30
  • Answering your question, Justin, requires a lot of background in low-level threaded OS architecture and applications. For example, a ThreadX OS has a minimum footprint of 2K (that's right) of RAM, providing all the features you need for task-based-threads. Performing particular tasks in ThreadX vs something like Linux isn't simply faster, it is millions of times faster. For example, boot time is measured in CPU cycles (300-400 required). For Linux, this number would be millions (or even billions). Read the http://rtos.com a bit to find out more. – Gary Wisniewski Dec 07 '15 at 02:21
  • sorry if this reply seems to be too late (it is a long time since i logged using this account last time): I do not completely agree with your comment, which is basically addressing the *speed* but not the deterministic character of an OS. And I think it is the later that makes an OS RTOS. – Justin Aug 16 '19 at 19:01

4 Answers4

3

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
VictorEE
  • 71
  • 5
  • Thank you for the response. but it appears to me that the quote from the ThreadX website is still telling *how fast* it is. I still cannot see what makes its response to external events *deterministic* – Justin Aug 16 '19 at 19:08
0

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

Tereus Scott
  • 674
  • 1
  • 6
  • 11
  • i wonder if having priorities for threads would make ThreadX a RTOS: general Linux provides different priorities to its processes, but we could not say Linux is an RTOS... – Justin May 09 '14 at 19:49
0

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.

Darshan Rajgor
  • 21
  • 5
0

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".

Andrés
  • 51
  • 3