We have developed a theoretical situation. It make a sense for me. Now I will try to make a real word example. Real world example means having a controller and input output devices.

I can imagine the situation but it very difficult to find its real world example.

I am just wondering what can be a real world example.

 

Don't try to hit the ball out of the park. Take small steps in a positive direction. You will not get to where you want to go overnight. If you want a real example, pick up a book and work your way through it. Even if it might be the "wrong" book, you'll learn something and you can resell it.

 

Don't try to hit the ball out of the park. Take small steps in a positive direction. You will not get to where you want to go overnight. If you want a real example, pick up a book and work your way through it. Even if it might be the "wrong" book, you'll learn something and you can resell it.

@Papabravo

The example given in the book is as below. I don't understand example for real world because there is only one critical task. That can be handle by normal process. there is no need for scheduler while I am looking for example that needs a preemptive scheduler

 

If these particular processes are considered in isolation you would be correct. I'm going to suggest that these are not isolated processes, but are part of a larger collection of processes that are competing for resources. In particular CPU time. It is indeed the case that a possible solution to a multi-tasking problem is to assign a single chip microcontroller to each process. There would be no task switching and very little overhead. This solution was not feasible at the dawn of the multi-tasking OS era (ca. 1965), but it is certainly feasible today.

 

For me it's not a disagreement on the usability of OOP in some programming arenas. We just shouldn't try to sell it as the solution to all programming arenas, with specificity to low-level embedded and systems bit-banging being an arena where OOP causes IMO a loss of clarity of the programming problem that's usually very precise, detailed and at times has only one correct solution as a set of sequences and procedures structured by fixed hardware. Programming in C while thinking about these types of sequence requirements is not Premature Optimization, it's a requirement for correctness of sequencing on each platform.

Agreed - A small program seldom needs anything but a functional programming style. I would never say that OOP is the right tool for every program and I don't think that anyone with any sort of experience would.

However if you are making an operating system you need it to scale well, and a little bit of abstraction will go a long way.

When designing an operating system you have now left the arena of bit banging and entered the area of more applied programming.

 

Agreed - A small program seldom needs anything but a functional programming style. I would never say that OOP is the right tool for every program and I don't think that anyone with any sort of experience would.

However if you are making an operating system you need it to scale well, and a little bit of abstraction will go a long way.

When designing an operating system you have now left the arena of bit banging and entered the area of more applied programming.

Sure. Using the Linux kernel and support modules (a fairly large program) as an example there is plenty of abstraction and OOP style where it's needed and helpful in the code using C and assembly.

Abstraction is already done in the kernel.
Encapsulation is already done in the kernel.
Polymorphism is already done in the kernel.

OO is much older than OO languages.

Designing an operating system is applied programming, actually implementing hardware directly on that operating system at the kernel level still is a large amount of bit-banging hardware registers in the correct sequence. It's better to use tools and programming methods designed and optimized for that so you can see why your elegant OS is crashing..