Sunteți pe pagina 1din 4

1.

in the context of FCFS scheduling, applications/


developers will use blocking system call APIs/
services of OS
--->this will lead to blocking of the current
active application/process and scheduler
will be invoked
--->calling/invoking system call APIs/services
is upto the developers/applications -
depends on requirements

--->refer to the lecture big-picture, but


each process/active appplication may
use unequal cpu execution times, based
on the execution times/blocking points,
as per requirements

2. in the case of time-slicing/RR scheduling


policy, the time-slice /time-quantum allocated
to each process will be fixed, a few milliseconds
- so, each process/active application is
allocated a fixed amount of cpu execution
time and preempted - this is repeated, for
every process/active application managed,
using time-slicing/RR policy
--->refer to the lecture diagrams

3. in most scenarios, basics remain the same,


but due to practical issues, certain
details will differ, but we need to adjust,
as per the scenario

4. blocking operations are common, in any


sw stack, including embedded and OS
platforms - meaning, it is true, in
non-OS platforms, as well
--->so, what does blocking mean, in
a non-OS/embedded platforms ??
-->one possible blocking mechanism
, in non-OS platforms is
, using delays/milli-seconds or
micro-seconds
--->another possibility is polling,
for IO events
--->there may be other mechanisms,
as well
--->in these contexts, the context
of execution will be main()
method of the embedded application

5. in the context of OS platforms, blocking


operations are managed differently -
the mechanisms are different

-->blocking involves processes/threads

--->in addition, blocking will add


the current process/thread to
a wq and state of the process/thread
will be set to blocked state
--->in addition, scheduler will be called
to select/dispatch another process/
thread

--->so, in OS blocking operations, during


blocking/waiting, the current process
/thread does not execute, whereas main()
method of an embedded application will
be busy-waiting,during its blocking
operations

--->so,blocking operations/mechanisms, in
OS platforms are more efficient, than
non-OS platforms, in general

---->as you do more practicals , you will


come more scenarios, for blocking
operations

6. in OS platforms, we may come across


different programming interfaces/
APIs
--->there are system call APIs
-->if we need to interface,
with OS, in user-space,
we need to use system call
APIs
--->many of the OS core services
are exported, using
system APIs - however,
there are certain core
services, which are not
exported, using system APIs

--->there are system APIs of


kernel/core
-->if our job/programming
is, in system-space,
system APIs are provided,
for accessing OS services
--->since there are certain OS
core services exported, using
system APIs, we need to access
these

--->there are RTOS APIs of


RTOS platforms

--->there may be other such


interfaces, OS platforms

--->in the context of embedded


sw platforms, without OS,
there are vendor libraries and
their interfaces

7. in a typical OS platform, many components


interact and work together
-->for instance, ISRs are OS-aware ISRs

--->which means, they will link /connect


to other components, like scheduler

--->in addition, certain policy decisions


are programmed into these OS-aware
ISRs

--->in the case of PRIO scheduling, if


an OS-aware ISR unblocks a process/pd
, if the unblocked process/pd is of
higher importance, ISR will trigger
/invoke the cpu scheduler - otherwise,
ISR will not trigger /program the
cpu scheduler - such details are part
of OS design

8. depending upon the design/implementation


of OS platforms, we may come across
the following issues :

--->certain OS platforms will support


more configurability, for the OS
features, like scheduling policies
--->GPOS will provide limited
configurability
--->embedded/RTOS platforms will
provide more configurations and
flexibility
--->refer to specific OS platform's
documentation
--->for changing the configuration settings,
there will system level configuration
parameters

--->in addition, on a per process basis,


we can change the scheduling parameters
of processes/active applications/
threads, as per our requirements
--->GPOS will provide system utilities
and system call APIs/system APIs
--->embedded/RTOS platforms, there
are system call APIs /system
APIs, as per the design/models

9. if there are several processes, with


TS policy and related non-RT priorities,
if one or more processes are assigned
FF/RR policies and RT priorities, the
latter processes will absolutely use
the cpu time, meaning the processes,
with TS policy/non-RT priorities will
be starved

10. in the case of kernel-space preemption,

int. event interrupts the system call


execution/service routine and this leads
to preemption/invokation of scheduler

--->in this case, what happens, if no


int. event occurs ??

--->in most cases, the service routine


will complete and there will be a return
to user-space/process and the user-space
process will resume execution, after
the system call API

--->one of the other possible conditions


is the system call service routine blocks
the current process and invokes the
scheduler, but this depends on the
characteristics of the system call
API and certain resource issues

--->in another possibility, the system


call service routine may unblock another
higher priority process and due to this,
scheduler is invoked by the system call
service routine - this will lead to
a preemption