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