Connect with us

What does Cooperative Multitasking mean?

Discussion in 'Microcontrollers, Programming and IoT' started by anukalp, Apr 27, 2020.

Scroll to continue with content
  1. anukalp

    anukalp

    32
    0
    Jul 28, 2018
    Definition
    Cooperative multitasking is a multitasking technique that enables two or more programs to cooperatively share the processing time and resources of the host processor

    There may be multiple task's to do, but processor only do one task at one time. scheduling algorithm decide when and which task, processor will complete

    I do not understand by the simple definition that what Cooperative multitasking does in real time system
     
  2. Harald Kapp

    Harald Kapp Moderator Moderator

    9,897
    2,096
    Nov 17, 2011
    anukalp likes this.
  3. anukalp

    anukalp

    32
    0
    Jul 28, 2018
    I have been gone through Wikipeadia as well as other websites. I need help to understand task states in real time system

    In typical designs, a task has three states:
    1. Running (executing on the CPU);
    2. Ready (ready to be executed);
    3. Blocked (waiting for an event).
    There may be multiple task running. When multiple task's running, processor will take one task it will run that task if there are events that have occurred It can be blocked running task. what Cooperative multitasking does in real time system
     
  4. Harald Kapp

    Harald Kapp Moderator Moderator

    9,897
    2,096
    Nov 17, 2011
    Cooperative multitasking requires that a running task voluntarily releases the processor to free it for the execution of other tasks.
    Or, in other words, if a task doesn't act in a cooperative way, it can block the processor and other tasks have no chance of being executed.

    This is in difference to preemptive multitasking where a central scheduler assigns cpu time to tasks and interrupts task to schedule cpu time for another task waiting for execution. In this scenario a running task can not block the cpu because the task will be interrupted by the scheduler.
     
  5. anukalp

    anukalp

    32
    0
    Jul 28, 2018
    Can the processor work like this

    EP.JPG
     
  6. Harald Kapp

    Harald Kapp Moderator Moderator

    9,897
    2,096
    Nov 17, 2011
    Please explain your diagram, I do not understand what you want to express with it.

    A state diagram needs to show not only states but also transitions to be meaningful.
     
    anukalp likes this.
  7. anukalp

    anukalp

    32
    0
    Jul 28, 2018
    I haven't drawn diagram for specific purpose. I would like to draw complete state diagram but i don't have the complete specification in mind. I'm looking for some useful example on the Internet. Once I make a specification, then I will try to make the state diagram,
    So that I will know which task should be run, when should be blocked, when should terminate.

    I am looking for example but I have not found a useful example yet, Can you give a hand made example or any useful example in any links?
     
  8. Harald Kapp

    Harald Kapp Moderator Moderator

    9,897
    2,096
    Nov 17, 2011
    hevans1944 and anukalp like this.
  9. hevans1944

    hevans1944 Hop - AC8NS

    4,459
    2,074
    Jun 21, 2012
    A real-time opeerating system (RTOS) never implements cooperative multitasking. It must implement pre-emptive multitasking with predictable and known latencies in the time required for task switching. In other words, it must be deterministic. It is particularly important that the interrupt service routines (ISRs) execute with a known and minimal latency, usually determined by hardware prioritization and other hardware considerations.

    Are you planning on writing, or learning to write, your very own RTOS? If so, do you have any particular processor or CPU in mind? For speed considerations, an RTOS is probably best written in assembly language for a particular CPU. If you can find the source code (it was published by DEC as "open source" back in the day) for RT11, a single-user RTOS, reading it and understanding what you read will reveal much about how to program an RTOS for a small computer.
     
    anukalp and Harald Kapp like this.
  10. anukalp

    anukalp

    32
    0
    Jul 28, 2018
    I am a planning to learn RTOS. I do not have good idea on RTOS. I am at beginner level I ma just reading Books, I am trying to understand why need rtos and how does it works. I do not understand two questions right now. I have also searched on google but i don't understand

    1. We can achieve anything by writing normal embedded program then why need RTOS ?
    Real time system has to respond on specific time limit. It has time-critical deadlines that must be met.

    single processor can not run multiple tasks at one time It can only run one task at one time. let say I have two task to complete. run motor and turn on off led. both task can't run at same time either we have to run motor or we have to turn on/off led

    2. What is meaning of task states (Ready to run, running, block ) in the context of Motor and LED task ?
     
    Last edited: Apr 29, 2020
  11. Harald Kapp

    Harald Kapp Moderator Moderator

    9,897
    2,096
    Nov 17, 2011
    The important part here is "specific time". It does not mean immediately, but the RTOS ensures that a program is assigned computing time at defined intervals in time so it can react to an event (e.g. an input from a sensor) within a guaranteed time.
    This is not the case with non-real-tome OS where one program can block others (you sure have seen this effect on your PC when you had to wait for a program to react while another program kept the PC busy).
    Right, but the CPU doesn't have to actively control the LEd or the motor all the time simultaneously. One process would turn the motor on, then the cpu is free to work on other processes (e.g. turn an LED on) until it comes back to the motor control process where it would inspect e.g. a speed sensor or position sensor to determine whether to let the motor run or turn it off. Then the scheduler would go on assign cpu time to the next process, e.g. LED control, where again sensors could be checked to turn the LED on or off.
    This all works as long as the cpu is much faster than the real world processes it has to control. From the viewpoint of the motor or the LED the cpu is constantly controlling either one. The motor is not aware of the cpu controlling the LED and vice versa.
    Once the real world processes become fast enough to notice the time lag incurred by the RTOS, it becomes time for a faster cpu or even a dedicated cpu to control that single fast process.

    The states of the process are not related to the states of the motor or the LED. The states of the process describe its behavior in the context of the operating system. There it may be waiting to be activated (ready to run), may be running (self explanatory), or blocked (waiting for e.g. some input).
    The motor has its own states: running and off (or even more like accelerating, decelerating depending on the application). For example the motor may be running once it has been turned on independent from the state of the process. Of course the motor control process needs to be active (running) in the context of the RTOS to change the state of the motor, but once it has done so (e.g. turned the motor off again), it may release control of the cpu and go back to e.g. "ready to run" once it has turned the motor off.

    Here's some more info for you to read.
     
    hevans1944 and anukalp like this.
  12. anukalp

    anukalp

    32
    0
    Jul 28, 2018
    superb explanation. I have seen in a book and also seen in some web site they only explain about task and task state, that I understand .

    I do not understand when I think of these three points in the context of devices such as led, motor, sensor display. Therefore, my intention was to understand three statements through motor and led task

    following are three point that I do not understand in context of led and motor
    1. If we have multiple ready task, then we can run one of them
    2. If any task is running on processor then we can also block the running task
    3. if any task is blocked it can be ready to run
     
  13. Harald Kapp

    Harald Kapp Moderator Moderator

    9,897
    2,096
    Nov 17, 2011
  14. anukalp

    anukalp

    32
    0
    Jul 28, 2018
    I am sorry but I have been searching since last two days but I do not understand clearly. so specific question, what is meaning of task is ready to be executed in the context of real time application?

    Exactly what happen in this state. Does any device stay on or off in this state. ?
     
  15. hevans1944

    hevans1944 Hop - AC8NS

    4,459
    2,074
    Jun 21, 2012
    To fully appreciate RTOS, or any operating system, you have to appreciate why any operating systems is needed. The link that @Harald Kapp provided is an excellent introduction to RTOS. After I visited it, I realized that it is no longer necessary to use assembly language to write efficient machine code instructions. C and C++ are widely supported and can be used with the API (Application Programming Interface) provided with freeRTOS. With gigabytes of memory and gigahertz processors now available at affordable prices, efficient coding no longer appears to be necessary.o_O Witness the explosion of bloatware, in the latter part of the previous century, that still goes on today.

    A task, or thread, is either running, blocked, or suspended in any operating system, either RTOS or a cooperative multi-tasking operating system.

    A running task has exclusive use of a CPU core, assuming a multi-core CPU which is common today, or exclusive use of a CPU if not a multi-core CPU. That means no other tasks or threads are executing on that particular CPU core.

    A blocked task is a task that is waiting for something (an event) to occur before it can continue executing. Blocked tasks still exist in executable memory, waiting to run after whatever blocked the task is removed. A multi-tasking operating system may transfer execution to another task, or thread, that is ready to run, at the discretion of the operating system.

    A suspended task is a task that could possibly be scheduled to run, but for some reason is neither running nor blocked. A suspended task may be removed from executable memory by the operating system to make room for other tasks to run, but the operating system remains aware of the state of the suspended task and may make it eligible to execute at a later time. Whether that happens or not depends on why the task was suspended, and what conditions are necessary to change the the state of the task from suspended to ready-to-execute.

    The operating system is responsible for changing the state of a task, or thread, from blocked or suspended to running or executing. None of this has anything at all to do with whether a device is on or off. Device states depend on hardware external to the computer on which the task is executing. Read the analogy below.

    Imagine for a moment that someone has given you the task of illuminating a room. You accept the task and move toward a light switch. You flip the light switch and the room is illuminated. Your task is finished and can now be suspended. You are no longer executing anything.

    Now imagine that you flip the switch and the room is NOT illuminated. You have no idea why, and no one has told you how, to correct the problem. Your task has been blocked, and again is no longer executing. Unless some other agent comes along to correct the problem, perhaps by changing a light bulb or paying the electric utility bill to restore power, your task will remain blocked. If whoever assigned you the task of illuminating the room notices, after awhile, that the room is still dark, they may terminate your task or suspend it. Either way, your task will not continue to execute. It may be removed from the "to do" list to allow you to perform other tasks.

    Computers are fast, much faster at accepting inputs and providing outputs than most real devices are capable of providing inputs or accepting outputs. There are of course exceptions, but you don't need to know about them right now. Some devices have input/output speeds that far surpass the processing capability of any computer available today, but for ordinary peripheral devices the CPU and its memory have plenty of "spare time" to service these "ordinary" peripherals and to execute other task threads as well.

    If you write a program to monitor keyboard key presses and display the results, perhaps as characters drawn on a CRT display or a flat-screen LCD, your program will spend most of its time in an idle loop, waiting for the slow human at the keyboard to type a key. And having detected a key stroke, the CPU will then spend a trivial amount of time updating the display screen before becoming idle again. Therefore, even for a single thread executing on a single core processor, a simple task as just described leaves plenty of idle processor time that could be used to run other threads... if only there were only an operating system to schedule and launch the execution of those other threads, as well as some way to stop a thread from executing so another thread could execute. And therein lies the rub. How exactly does a programmer write an operating system that allows all that to happen in a reasonable, non-contentious manner?

    A general solution is a pretty big task for a lone programmer! Thank goodness there have been tens of thousands of man-years already dedicated to perfecting this big task. And plenty of documents that describe exactly how it is done. The specific details will depend on the processor (CPU) used and how the operating system is required to respond to blocked tasks, such that all blocked tasks can eventually be allowed to execute or run, at least in theory. There may be real-world situations where a task must never be blocked and must always be allowed to run. That means a dedicated (embedded) processor is required, and that this processor executes only that one task. In such a situation, a multi-tasking operating system is hardly necessary, or even desirable.

    But even a primitive operating system, not necessarily an RTOS, is often desirable for processors executing dedicated task threads, if for no other reason than program development. Programmers need to use editors to create source files for storage on hard disk drives (or other storage devices), and compilers are needed to translate source code written in C or C++ or some other language into machine code, and often loaders are needed to re-locate machine code to arbitrary, available, contiguous areas of random access memory for execution. All of these tasks could share available execution time on any modern microprocessor without any outward indication that the tasks are not executing simultaneously, but most of the time they don't... unless the operating system supports task switching among multiple executing tasks... a multi-tasking operating system in other words. And of course, it is not unusual to develop programs on one computer for downloading and executing on another. In fact, that is the current paradigm for embedded computer applications, supported by various flavors of Windows and Unix or Linux, which are all multi-tasking operating systems. And then there is Apple, but I digress...

    The how and when of task switching helps to define and separate a pre-emptive RTOS from a cooperative operating systems. A cooperative task-switching operating system, such as Windows 10, depends on task threads voluntarily interrupting their execution to allow another task thread the opportunity to execute. This usually occurs when the running task becomes blocked (from executing) because it is waiting for something to happen. If whatever it is waiting for never occurs, the system "hangs" until something happens that allows the operating system to terminate the task thread. Pulling the plug from the power outlet, waiting ten seconds, and plugging it back in again usually "un-hangs" the computer, but there are better ways to recover when threads are blocked.

    A simple hardware interrupt, controlled by a periodic "tick" from an on-board clock oscillator, will usually suffice to get things moving again by interrupting a blocked thread and returning CPU control to the operating system. But in a cooperative task-switching operating system this should never be the way a blocked task thread is automatically suspended and prevented from continued execution. Timer interrupts used to un-block a "hung" task thread are "last ditch" efforts by the operating system to restore normal execution when a poorly written task fails to cooperate.

    Task blocking also occurs in an RTOS, but it never causes the system to "hang" because the RTOS is written to allow pre-emptive interruption of a blocked task by the RTOS task scheduler, which then ques another task thread to run. What makes an RTOS operate in "real time" is the deterministic nature of everything that it does, and most especially the time response to events. Most events will assert a hardware interrupt to get the attention of the CPU, pre-emptively interrupting whatever program thread was executing when the interrupt event occurred. To service an interrupt event, the CPU must save information concerning its state when the interrupt occurred, transfer execution to an interrupt service routine (ISR), and then restore the saved previous state to allow execution of the interrupted thread to continue. This context switching takes time of course, and the ISR must minimize how long it takes to perform its task before returning control back to the thread that was interrupted. Usually (but not always) further interrupts are disabled when the ISR executes, and the last thing the ISR does before exiting (returning) is to enable interrupts again. However, it is conceivable that a hardware interrupt is asserted by a complex peripheral that requires further processing in cooperation with other peripherals, in which case the ISR may only perform a minimum of functions before enabling interrupts again, which would allow those other peripherals to assert another (hardware) interrupt before the first peripheral ISR was finished. This nesting of interrupts is tricky and requires precise knowledge of the timing requirements for all peripherals involved in order to allocate priority of response to interrupt requests.

    All of the above is definitely not something a beginner should tackle, if the goal is to understand how an RTOS works and why it is needed. You should first try to discover under what conditions an RTOS is absolutely necessary.

    I once had a customer who had a complex electro-hydraulic environmental simulator that was an all-analog system designed and built in the 1950s right after the USSR launched its Sputnik satellite, which capability scared the hell out of USA defense department military guys. Intel 386-based PCs were just becoming widely available in the 1980s, and Microsoft was on about its third or fourth version of its Windows Cooperative Multi-tasking Operating System, which was still buggy as hell. But this customer wanted us to "upgrade" his system by replacing all the proportional-control, high-volume, high-pressure, Moog hydraulic servo valves (there were six of them IIRC) with digital versions, and to control those valves with a PC running Windows. Our company accepted the job and I was assigned as the engineer in charge of the project, knowing that Microsoft Windows would not be capable of the real-time task of lifting and maneuvering some twenty tons of hardware around.

    The environmental simulator was large enough to drive a Volkswagon into it. It had huge external vacuum pumps to simulate the atmosphere inside of it at a classified (but very high) altitude, and radiant heaters, also inside the chamber, to simulate the heating effect of sunlight, and a refrigerated cooling radiator inside to simulate the cooling effects of the upper atmosphere. All this was used to performance test classified airborne imaging systems. When not in use, the weight of the environmental chamber was supported on three retractable pylons. To operate it, the hydraulic system lifted it off the pylons, retracted the pylons out of the way, and then executed an analog program (stored on magnetic tape) that directed how the chamber was to be moved around in roll, pitch, and yaw to simulate the motions of whatever classified airborne platform carried the imaging system equipment.

    I was allowed to assemble a team consisting of a competent electronics technician and a very competent software guy. Almost immediately we ruled out using Windows and instead purchased a version of Unix that had a real-time OS kernel. We used the free X-Windows application program to provide similar functionality to Microsoft Windows and a graphical user interface for the operator. In many ways X-Windows was superior ot Microsoft Windows, and the liaison person the customer provided didn't seem to care as long as the system we provided worked. It took the three of us more than a year to re-wire the existing machine and to get the program working, but in the end it was a huge improvement in capability over the original.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-