Gantt Charts



Turnaround Time - From point of view of particular process, important criterion is how long it
takes to execute that process. The interval from the time of submission of a process tothe time of
completion is the turnaround time. Turnaround time is the sum of the periods spent waiting to get
into memory, waiting in the ready queue, executing on the CPU, and doing I/O.
Waiting Time - The CPU-scheduling algorithm does not affect the amount of time during which a
process spends waiting in the ready queue. Waiting time is the sum of the periods spent waiting in
the ready queue.
Response Time - In an interactive system, turnaround time may not e the best criterion. Often, a
process can produce some output fairly early and can continue computing new results while
previous results are being output to the user. Thus, another measure is the time from the
submission of a request until the first response is produced. This measure, called response time is
the time it takes to start responding, not the time it takes to output the response. The turnaround
time is generally limited by the speed of the output device.
Threading
Benefits of threading
Responsiveness - Multithreading an interactive application may allow a program to continue running even
if part of its blocked or is performing a lengthy operation, thereby increasing responsiveness to the user.
For instance, a multithreaded Web browser could allow user interaction in one thread while an image was
being loaded in another thread.
Resource Sharing - Processes may only share resources through techniques such as shared memory or
message passing. Such techniques must be explicitly arranged by the programmer. However, threads
share the memory and the resources of the process to which they belong by default. The benefit of sharing
code and data is that it allows an application to have several different threads of activity within the same
address space.
Economy - Allocating memory and resources for process creation is costly. Because threads share the
resources of the process to which they belong, it is more economical to ccreate and context-switch threads.
Empirically gauging the difference in overhead can be difficult, but in general it is much more time
consuming to create and manage processes than threads. In Solaris, for example, creating a process is
about thirty times slower than is creating a thread, and context switching is about five times slower.
Scalability - The benefits of multithreading can be greatly increased in a multiprocessor architecture,
where threads may be running in parallel on different processors. A single-threaded process can only run
on one processor, regardless how many are available. Multithreading on a multi-CPU machine increases
parallelism.
Deadlocks
Process may utilize a resource in the following sequence:

Request - a process requests resources and waits.


Use - Process operates on resource.
Release - Process releases resource.
Conditions for Deadlock:




Mutual Exclusion - Only one process at a time can use a resource
Hold and Wait - Process must be holding >= 1 resources and wait to acquire more resources that
are being used by other processes
No preemption - Resource can be released only voluntarily by process using it
Circular Wait - For a set {p0, p1, ... pN}, of waiting processes, p0 is waiting for a resource from
p1, p1 waits on p2, ... , pN waits p0.
Methods for Handling Deadlock:



Use of a protocol to prevent or avoid deadlock
Allow deadlock, detect it, and recover
Ignore the problem and pretend deadlocks never occur (used when it is believed that the
deadlocks will be extremely rare)
Starvation:

Process can't get the resources necessary to complete. Another process that holds the needed
resources may release it, but it gets it back before the starving process can get it.
Context Switch
Context Switch during a system call
1. Save State
2. Flush Caches
3. Switch from user virtual memory to kernel virtual memory
4. Mark cache as invalid
5. Set priority to 1 (for kernel privileges)
6. Set state (may not overwrite all the registers, some may be used to pass arguments/parameters)
Mutexes and Semaphores
~Semaphores~
A semaphore S is an integer variable that, apart from initialization, is accessed only through two
standard atomic options:wait() and signal(). The wait() operation was originally termed P (from
the Dutch proberen, "to test"); signal() was originally called V (from verhogen, "to increment").
The definition of wait() is as follows:
wait(S) {
while S <= 0
;
S--;
}
The definition of signal is as follows:
signal(S) {
S++;
}
All modifications to the integer value of the semaphore in the wait() and signal() operations must
be executed indivisibly. That is, when one process modifies the semaphore value, no other
process can simultaneously modify that same semaphore value. In addition, in the case of wait(S),
the testing of the integer value of S (S <= 0), as well as its possible modification (S--), must be
executed without interruption.
Usage~~
Operation systems often distinguish between counting and binary semaphores. The value of a
counting semaphore can range over an unrestricted domain. The value of a binary semaphore can
range only between 0 and 1. On some systems, binary semaphores are known as mutex locks, as
they are locks that provide mutual exclusion.
We can use binary semaphores to deal with the critical-section problem for multiple processes.
The n processes share a semaphore, mutex, initialized to 1. Counting semaphores can be used to
control access to a given resource consisting of a finite number of instances. The semaphore is
initialized to the number of resources available. Each process that wishes to use a resource
performs a wait() operation on the semaphore (thereby decrementing the count). When a process
releases a resource, it performs a signal() operation (incrementing the count). When the count for
the semaphore goes to 0, all resources are being used. After that, processes that wish to use a
resource will block until the count becomes greater than 0.
We can also use semaphores to solve various synchronization problems. For example, consider
two concurrently running processes: P1 with a statement S1 and p@ with a statement S2.
Suppose we require that S2 be executed only after S1 has completed. We can implement this
scheme readily by letting P1 and P2 share a common semaphore synch, initialized to 0, and by
inserting the statements
S1;
signal(synch);
in process P1 and the statements
wait(synch);
S2;
in process P2. Because synch is initialized to 0, P2 will execute S2 only after P1 has invoked
signal(synch), which is after statement S1 has been executed.
Extended file system
ext
Full name
Extended file system
Introduced
April 1992 (Linux)
Structures
File allocation
bitmap (free space), table
(metadata)
Bad blocks
Table
Features
File system
permissions
POSIX
Transparent
encryption
No
The extended file system, or ext, was implemented in April 1992 as the first file system created
specifically for the Linux kernel. It has metadata structure inspired by the traditional Unix File System
(UFS) and was designed by Rémy Card to overcome certain limitations of the MINIX file system.[1] It was
the first implementation that used the virtual file system (VFS), for which support was added in the
Linux kernel in version 0.96c, and it could handle file systems up to 2 gigabytes (GB) in size.[2]
It is the first in the series of the extended file systems, superseded by both ext2 and xiafs, between
which there was a competition, which ext2 won because of its long-term viability. ext2 remedied issues
with ext, such as the immutability of inodes and fragmentation
EXT2
The ext2 or second extended filesystem is a file system for the Linux kernel. It was initially designed by
Rémy Card as a replacement for the extended file system (ext).
The canonical implementation of ext2 is the ext2fs filesystem driver in the Linux kernel. Other
implementations (of varying quality and completeness) exist in GNU Hurd, MINIX 3, Mac OS X (thirdparty), Darwin (same third-party as Mac OS X but untested), some BSD kernels, in Atari MiNT, and as
third-party Microsoft Windows drivers.
ext2 was the default filesystem in several Linux distributions, including Debian and Red Hat Linux, until
supplanted more recently by ext3, which is almost completely compatible with ext2 and is a journaling
file system. ext2 is still the filesystem of choice for flash-based storage media (such as SD cards, and USB
flash drives), since its lack of a journal minimizes the number of writes, and flash devices have a limited
number of write cycles. Recent kernels, however, support a journal-less mode of ext4, which would offer
the same benefit, along with a number of ext4-specific benefits.
ext3, or third extended filesystem, is a journaled file system that is commonly used by the Linux kernel.
It is the default file system for many popular Linux distributions, including Debian. Stephen Tweedie first
revealed that he was working on extending ext2 in Journaling the Linux ext2fs Filesystem in a 1998 paper,
and later in a February 1999 kernel mailing list posting. The filesystem was merged with the mainline
Linux kernel in November 2001 from 2.4.15 onward.[2][3][4] Its main advantage over ext2 is journaling,
which improves reliability and eliminates the need to check the file system after an unclean shutdown.
Its successor is ext4.
Advantages
The performance (speed) of ext3 is less attractive than competing Linux filesystems, such as ext4, JFS,
ReiserFS and XFS. But ext3 has a significant advantage in that it allows in-place upgrades from ext2
without having to back up and restore data. Benchmarks suggest that ext3 also uses less CPU power
than ReiserFS and XFS.[5][6] It is also considered safer than the other Linux file systems, due to its relative
simplicity and wider testing base.[7][8]
ext3 adds the following features to ext2:



A journal.
Online file system growth.
Htree indexing for larger directories.[9]
Without these features, any ext3 file system is also a valid ext2 file system. This situation has allowed
well-tested and mature file system maintenance utilities for maintaining and repairing ext2 file systems
to also be used with ext3 without major changes. The ext2 and ext3 file systems share the same
standard set of utilities, e2fsprogs, which includes an fsck tool. The close relationship also makes
conversion between the two file systems (both forward to ext3 and backward to ext2) straightforward.
ext3 lacks "modern" filesystem features, such as dynamic inode allocation and extents. This situation
might sometimes be a disadvantage, but for recoverability, it is a significant advantage. The file system
metadata is all in fixed, well-known locations, and data structures have some redundancy. In significant
data corruption, ext2 or ext3 may be recoverable, while a tree-based file system may not.
ext3 Developer Stephen Tweedie Full name Third extended file system Introduced November 2001
(Linux 2.4.15) Partition identifier 0x83 (MBR)
EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT) Structures Directory contents Table, hashed B-tree
with dir_index enabled File allocation bitmap (free space), table (metadata) Bad blocks Table Limits Max
file size 16 GiB – 2 TiB Max number of files Variable, allocated at creation time[1] Max filename length
255 bytes Max volume size 2 TiB – 16 TiB Allowed characters in filenames All bytes except '\0' and '/'
Features Dates recorded modification (mtime), attribute modification (ctime), access (atime) Date range
December 14, 1901 - January 18, 2038 Date resolution 1s Attributes allow-undelete, append-only, h-tree
(directory), immutable, journal, no-atime, no-dump, secure-delete, synchronous-write, top (directory)
File system permissions Unix permissions, ACLs and arbitrary security attributes (Linux 2.6 and later)
Transparent compression No Transparent encryption No (provided at the block device level) Data
deduplication No Supported operating systems Linux, BSD, Windows (through an IFS)
BFFS
A UFS volume is composed of the following parts:



a few blocks at the beginning of the partition reserved for boot blocks (which must be initialized
separately from the filesystem)
a superblock, containing a magic number identifying this as a UFS filesystem, and some other
vital numbers describing this filesystem's geometry and statistics and behavioral tuning
parameters
a collection of cylinder groups. Each cylinder group has the following components:
o a backup copy of the superblock
o a cylinder group header, with statistics, free lists, etc., about this cylinder group, similar
to those in the superblock
o a number of inodes, each containing file attributes
o a number of data blocks
Inodes are numbered sequentially, starting at 0. The first two inodes are reserved for historical reasons,
followed by the inode for the root directory, which is always inode 2.
Directory files contain only the list of filenames in the directory and the inode associated with each file.
All file metadata is kept in the inode.