Is it necessary to code RTOS in C language always? Why can't that be coded in java or some other technology..?? Is that because of the absence of pointer concept in java?
Garbage collection is the big reason against Java being Real Time. JIT is another, but it could be overcome.
In general though, C being effectively portable assembly gives very predicable run-time performance, and that's essential for reliable real-time execution.
Real time systems can be programmed in other languages too. Java has a Java RTS System for example.
Contrary to other answers, there is reasonable amount of work on real-time garbage collections. However, these don't get bundled in your typical distributions.
The concern is that other languages usually have features that make determinism and reliability hard to achieve, e.g traditional garbage collection, JIT, run-time optimizations, etc.
At first RTOS aren't just coded in C. They can also be coded in other languages. However the language used for an RTOS needs to offer deterministic behaviour. This means that the latency for a specific action must always be under a specific amount of time. This rules out for example garbage collection, which in most implementations will stop the execution of all threads for an undetermined time.
Because RTOS developers, most likely, don't know C++ well enough.
C++ in Embedded Systems: Myth and Reality
Some perceive that C++ has overheads and costs that render it somehow unsuited to embedded systems programming, that it lacks the control and brevity of C, or that, while it may be suited to some niche applications, it will never displace C as the language of choice for embedded systems.
These perceptions are wrong. Where compilers and other tools are adequate, C++ is always preferable to C as an implementation language for embedded systems. While doing everything that C does, it offers greater opportunities for expression, encapsulation, re-use, and it even allows size and speed improvements that are impractical in C.
> Why, then, do these perceptions persist? The main reason is that when people form their opinions, they know a lot more about C than about C++. They have read some books, written some code, and are competent at using the features of C++, but they lack the knowledge of what is happening under the hood, the familiarity that allows one to visualize the disassembly while typing source or even while formulating a design.
Guidelines for using C++ as an alternative to C in embedded designs
Embedded software applications are most commonly written in C. For many years, C++ has been seen as the natural successor and has found greater acceptance, but the increase in its usage has been much slower than anticipated.
There are a number of reasons for this. Firstly, embedded developers are quite conservative and prefer to use solutions that are proven rather than novel " "if it ain't broke, don't fix it".
There is also the lesson of experience. Many developers have attempted to use C++ for embedded applications and failed. Such failures may sometimes be attributed to shortcomings in development tools, but most often it is the inappropriate use of the language " treating an embedded system like a desktop computer " that is to blame.
Limitations of C Although C is widely used, it has limitations, as it was not designed for embedded applications or for projects of a scale that is now commonplace. Key limitations include:
1) C is extremely powerful and flexible and can therefore be dangerous.(It has low level capabilities - which are useful for embedded " but also represent many pitfalls for the unwary.)
2) Programmers need to be very methodical and disciplined
3) Programmers need to understand how the program behaves at low and high levels (large projects are thus hard to maintain)
4) Programmers need an expert knowledge of the application
However, C++ has powerful object oriented capabilities which can help significantly with addressing the limitations of C:
1) it encapsulates and hides areas of high expertise from non-experts into "objects;" (A test case will demonstrate the encapsulation of expertise later in Part 2 in this series).
2) Objects can be used intuitively by non-experts to implement conceptual designs at a high-level
Not "necessary", but a lot more practical
As a language Java could be used, and there are various wacky cases of it actually happening.
But a few fringe cases and demonstrations are really more "the exception(s) that prove the rule".
In general, Java is a big elaborate system intended for business logic and not OS kernels.
If we did not already have C, Java might have developed in a different direction, or in multiple directions.
But we do have C, which is nearly perfect for an OS kernel and quite a challenge for business logic.
Arguments that Java is just as good as C for a kernel are about as realistic as arguments that C is just as good as Java for applications. Experience, minus a few fringe examples, proves overwhelmingly what each language is good for.
- Availability of highly optimized c-compilers for all hardware that RTOS-es typically run on.
- The relative ease with which you can include very low level optimizations in c-code.
- Availability of c-code for a lot of useful low-level system tools which hence can easily be incorporated.
By definition an RTOS must support deterministic scheduling and execution. Generally low interrupt latency, and direct hardware access are also a desirable factor. Technologies used in Java such as garbage collection, JIT compilation, and bytecode execution make these goals hard to achieve.
Java may be used in real-time systems, but typically it runs on an RTOS rather than being used in its implementation.
All that said, it would equally be untrue to suggest that RTOS are always implemented in C. Any systems level language would be suitable including assembler. In most cases at least some part of the kernel would be in assembler in any case. C++ would be a suitable language (rather obviously since it is essentially a C superset), many commercial RTOSs have C++ wrappers in any case; I habitually develop C++ abstraction layers for RTOS to support portability.
The other reason C is typically used is because a C (often a C/C++) compiler is generally the first and often the only language (other than assembler) available for a new architecture (frequently these days in the form of a GNU compiler implementation). So if you want to be able to port your RTOS to the widest number of platforms, it makes sense to use the most ubiquitous language.
I think the biggest problem with java for this purpose is the automatic garbage collection. Here's a link on creating realtime systems in java.
Because C-based RTOS are well known and have been used for many decades. Their behaviour is predictable for many specific situations and you can find many experts for developing with these systems.
I know no Java-based RTOS having reached a level such that a company making safety critical realtime applications would adopt it.
Technically, there is no argument against a Java-based RTOS, but research, engineering and products on the subject is not yet mature.
There's Real Time in Java, but it requires support from the OS. See: http://java.sun.com/javase/technologies/realtime/index.jsp
Is it necessary to code RTOS in C language always?
No. You can code RTOS also in assembler, Ada and few other.
Why can't that be coded in java or some other technology..?? Is that because of the absence of pointer concept in java?
No. Unpredictable time of code execution.
C was designed for writing operating systems, hence the common wording "portable assembler", so it is to be expected that it is used for that purpose.
If you want to have real time Java, Sun has a commercial offering.
If anything, it's because of pointers. In Java, everything except fundamental data types is allocated on the heap, and any variable that isn't something like int is a pointer. That's not a good way to write an operating system, because it imposes one layer of indirection over most operations, and in OS writing that layer can kill you.
The OS kernel is a place where you want optimization and high performance, since you don't know what will run on it. This is particularly true of real-time OSs, in which a half-millisecond delay can be critical. This requires getting really chummy with the CPU and other hardware, and the ability to write highly microoptimized code that will execute specific things with great predictability.
For this reason, C is a very good tool to build a RTOS kernel with, and Java isn't. That doesn't mean you couldn't do it with Java, but it would be harder and probably not as successful.
I am curious as to why you ask the question. If you're using a RTOS, it doesn't really matter what it was written in. If you want to hack one, it does matter what it was written in, but the concepts and implementation of the OS are sufficiently hard in themselves that learning a new language is trivial to learn. (Moreover, if you study OS design and implementation, you're almost certain to find that the resources you use will use C as a teaching language.)
An RTOS isn't always written in C. Usually it is so, but in ThreadX I believe they use assembly.
A garbage-collected language like Java is highly unsuited for real-time programming. The reasons for this should be obvious.
Is it necessary to code RTOS in C language always?
No. There are RTOS written in Lisp or Smalltalk, for example.
Why can't that be coded in java or some other technology..??
What makes you think it can't?
Is that because of the absence of pointer concept in java?
No, it's because there is a myth that Operating Systems can only be written in C. A myth that can be trivially proven false, yet still refuses to die.
This myth is so pervasive, that people who want to write a new OS, are simply too afraid to try anything other than C.
来源：https://stackoverflow.com/questions/1927229/why-are-rtos-coded-only-in-c