Need some detail information on Hard Real-Time Systems and Soft real-Time Systems.
 

Respected Sirs,

I need to know the meaning of Hard-real time systems and soft-real time systems.

Also,
What kind of applications can be considedred as Hard-Real time and what kind of applications cab be considred as Soft-Real time.

What is the difference in the way hard real-time and soft-real time should be treated?

Thanks,

Maybe you've already read this, but it's worth reading.

Also, we talked about real time OS's in my college. Real time really has to do with the OS architecture and such. A lot of core components of the kernel are different in a RT OS than a regular OS kernel; scheduler, the way a process 'asks' for time on the cpu, etc. The link above can tell you more.

Lot's of times, a real time OS will require a process to know certain things about itself before it lets it run on the cpu. One of those things may be the amount of time it needs to run on the cpu. If the scheduler of the RT OS knows that it will not be able to complete the task requested by a process, it will fail it and not even run it.

The wikipedia article quoted above is certainly worth reading, and it describes the answer to your question correctly, but it isn't quite correct in some other respects:

The thing to remember about hard real time is that the system has failed if the response does not arrive on time; for soft real time, some degree of lateness can be tolerated - for example, in 1% of cases, the system response was late, but it was on time in 99% of cases. This may well be tolerable in a soft real time system (there will probably be a system specification for the maximum allowable lateness rate), but certainly isn't if the system is truly hard real time.

Their example of a video streaming system is an interesting one - some dropped frames could be tolerable, but has the system failed?

It is also the case that the usual case is that with a hard real time system, something pretty bad happens when the system fails. For most of us, injury or loss of life are pretty bad consequences but a dropped frame of video isn't. Allthough you could probably argue that it depends what you are using the video for, I suppose. You know, critically monitoring the innards of a nuclear reactor is a bit different from a wedding video.

You should also note that real time, and particularly hard real time, is sometimes confused with 'fast'. Fundamentally, these are different concepts.

To add to what salasi has already posted, this question really doesn't make sense. The vast majority of applications are not real-time at all. Even when working with a real-time system, "does this particular job require real-time processing" is not even the first question you ask; you start from questions such as "what are the tolerable latencies" and "can I miss some small amounts of data or must it absolutely all be processed" and from there a multitude of other questions come up. Come to think of it, in my experience the question "do we need a real time kernel" has never come up. However, in working out the requirements for a particular job it has sometimes been concluded that a real-time kernel is essential. The decision to use a real-time kernel comes from the analysis of the requirements, examination of the proposed system, expected and measured latencies, and a number of other factors.

Use of real-time systems often (but not always) comes up in signal measurement systems.

In my experience when someone says "I need a real-time system", over 90% of the time they don't know what they're talking about and in fact do not need a real-time system. (Maybe one day I'll be exposed to more intelligent people.) There is no simple rule for determining whether you do or don't need a real-time system.

SO - if you want examples of real-time programs, you'll simply have to scour the internet for those examples. Odds are even among the "real-time" programs you find, many of them will not really have a "real-time" requirement and would work just as well on an ordinary system with the stock scheduler and even under moderate to high CPU loading. That is why the question about what real-time programs are out there really makes little sense.