interprocess communication

• Direct communication

When communication is direct, a person means exactly what they say. There is no implied meaning, insinuation, or mixed message. Think of a scientist saying “The results of the experiment are positive”, or a journalist saying ”The accident occurred at 6pm”; this is direct communication. When you say "I like your clothes", and you are being direct, you mean you like the other person's clothes. People can communicate how they feel by being direct. For example, "I feel hurt that you didn't meet me yesterday" (this is sometimes called an "I-statement").
When being direct, the speaker's tone of voice is usuall "plain" (even monotome), because they are not using a sarcastic or defensive tone (or any other inflection that creates a mixed message). Direct communication is the only form of communication in many fields, such as science, journalism, and in the legal system (a defendant would not plead guilty in court sarcastically, because the sarcastic tone would be disregarded and it would count as a real guilty plea).
In all important matters in society, people use direct communication. For example, when an airplane communicates with air traffic control, they say directly and exactly what they mean, in very specific terms. They don't use sarcasm or imply things, since the situation is too important to allow for any misunderstanding.

• Indirect communication

By comparison, indirect communication conceals one's true position or feelings. There are may ways to be indirect, an obvious example is sarcasm. If you don't like someone's clothes and you say (in a sarcastic tone) "I like your clothes", the literal meaning and implied meaning are opposite.
While direct communication has a goal of cooperation, indirect communication has a goal of hurting or manipulating another person, or protecting one's self. Below is an incomplete list of some different forms of indirect communication, grouped into attacks and defenses, along with a description.

• synchronization

1. Blocking send-- caller blocked until send is completed


2. non-blocking send--caller blocked until receive is finished


3. blocking receiver --receiver blocks until message is available


4. non-blocking receiver --receiver retrieves a valid message or returns an error code

• buffering

1. zero capacity-

• sender blocks until receiver is ready

• otherwise, message is lost

2. bounded capacity-

• when buffer is full, sender blocks

• when buffer is not full, no need to block sender

3. unbounded capacity-

no need to block sender

• producer-consumers example

produce-- info to be consumed by consumer

consume-- information produced by producer

Inter-process communication (IPC)

Inter-process communication (IPC) is a set of techniques for the exchange of data among multiple threads in one or more processes. Processes may be running on one or more computers connected by a network. IPC techniques are divided into methods for message passing, synchronization, shared memory, and remote procedure calls (RPC). The method of IPC used may vary based on the bandwidth and latency of communication between the threads, and the type of data being communicated.
There are several reasons for providing an environment that allows process cooperation:
Information sharing
Computation speedup
Modularity
Convenience
IPC may also be referred to as inter-thread communication and inter-application communication.
IPC, on par with the address space concept, is the foundation for address space independence/isolation.

cooperating process

cooperating process-A process which can affect or can be affected by other processes is called cooperating process.

process operation

Process Operation -- Starting, controlling, and ending a process or procedure.

1. process creation-

A process operates in a cycle consisting of the following steps:
1.
the process is awakened by one of the awaited events
2.
the process responds to the event, i.e., executes a fragment of its code method
3.
the process puts itself to sleep
Before a process puts itself to sleep, it usually issues at least one wait request--to specify the event(s) that will wake it up in the future. A process may also issue a persistent wait request (see section 3.3.2), to be restarted cyclically by the subsequent occurrences of the same event. A process that goes to sleep without specifying a single waking condition is terminated. There is no sense to keep such a process around, as it will never run again. The effect is exactly the same as if the process performed delete on its object handle as its last statement (section 3.2).
To put itself to sleep, a process (its code method) can execute the following statement: sleep
or simply return from the code method.
The following operation handles wait requests:
wait ai event state priority
Only the first two arguments are mandatory. The first of them identifies the agent (the so-called activity interpreter (AI for short) responsible for triggering the waking event; the second argument specifies the actual event.
Activity interpreters are discussed in section 4. We saw one of them, the timer, in the example in section 3.2. In that case, the event was the delay in milliseconds after which the timer was expected to go off.
Argument state is optional and defaults to an empty string. It specifies the state to be assumed when the awaited event wakes up the process. This state will be returned in the process attribute State which can be examined by the code method.

2.process termination-

Process termination
Processes terminate in one of two ways:

Normal Termination occurs by a return from main or when requested by an explicit call to exit or _exit.
Abnormal Termination occurs as the default action of a signal or when requested by abort.
On receiving a signal, a process looks for a signal-handling function. Failure to find a signal-handling function forces the process to call exit, and therefore to terminate. The functions _exit, exit and abort terminate a process with the same effects except that abort makes available to wait or waitpid the status of a process terminated by the signal SIGABRT (see exit(2) and abort(3C)).
As a process terminates, it can set an eight-bit exit status code available to its parent. Usually, this code indicates success (zero) or failure (non-zero), but it can be used in any manner the user wishes. If a signal terminated the process, the system first tries to dump an image of core, then modifies the exit code to indicate which signal terminated the process and whether core was dumped. This is provided that the signal is one that produces a core dump (see signal(5)). Next, all signals are set to be ignored, and resources owned by the process are released, including open files and the working directory. The terminating process is now a ``zombie'' process, with only its process-table entry remaining; and that is unavailable for use until the process has finally terminated. Next, the process-table is searched for any child or zombie processes belonging to the terminating process. Those children are then adopted by init by changing their parent process ID to 1). This is necessary since there must be a parent to record the death of the child. The last actions of exit are to record the accounting information and exit code for the terminated process in the zombie process-table entry and to send the parent the death-of-child signal, SIGCHLD (see ``Signals, job control and pipes'').
If the parent wants to wait until a child terminates before continuing execution, the parent can call wait, which causes the parent to sleep until a child zombie is found (meaning the child terminated). When the child terminates, the death-of-child signal is sent to the parent although the parent ignores this signal. (Ignore is the default disposition. Applications that fork children and need to know the return status should set this signal to other than ignore.) The search for child zombies continues until the terminated child is found; at which time, the child's exit status and accounting information is reported to the parent (remember the call to exit in the child put this information in the child's process-table entry) and the zombie process-table entry is freed. Now the parent can wake up and continue executing.

process scheduling

1.The scheduler is the component of the kernel that selects which process to run next. The scheduler (or process scheduler, as it is sometimes called) can be viewed as the code that divides the finite resource of processor time between the runnable processes on a system. The scheduler is the basis of a multitasking operating system such as Linux. By deciding what process can run, the scheduler is responsible for best utilizing the system and giving the impression that multiple processes are simultaneously executing.
The idea behind the scheduler is simple. To best utilize processor time, assuming there are runnable processes, a process should always be running. If there are more processes than processors in a system, some processes will not always be running. These processes are waiting to run. Deciding what process runs next, given a set of runnable processes, is a fundamental decision the scheduler must make.
Multitasking operating systems come in two flavors: cooperative multitasking and preemptive multitasking. Linux, like all Unix variants and most modern operating systems, provides preemptive multitasking. In preemptive multitasking, the scheduler decides when a process is to cease running and a new process is to resume running. The act of involuntarily suspending a running process is called preemption. The time a process runs before it is preempted is predetermined, and is called the timeslice of the process. The timeslice, in effect, gives each process a slice of the processor's time. Managing the timeslice enables the scheduler to make global scheduling decisions for the system. It also prevents any one process from monopolizing the system. As we will see, this timeslice is dynamically calculated in the Linux scheduler to provide some interesting benefits.
Conversely, in cooperative multitasking, a process does not stop running until it voluntary decides to do so. The act of a process voluntarily suspending itself is called yielding. The shortcomings of this approach are numerous: The scheduler cannot make global decisions regarding how long processes run, processes can monopolize the processor for longer than the user desires, and a hung process that never yields can potentially bring down the entire system. Thankfully, most operating systems designed in the last decade have provided preemptive multitasking, with Mac OS 9 and earlier being the most notable exceptions. Of course, Unix has been preemptively multitasked since the beginning.
During the 2.5 kernel series, the Linux kernel received a scheduler overhaul. A new scheduler, commonly called the O(1) scheduler because of its algorithmic behavior1, solved the shortcomings of the previous Linux scheduler and introduced powerful new features and performance characteristics. In this section, we will discuss the fundamentals of scheduler design and how they apply to the new O(1) scheduler and its goals, design, implementation, algorithms, and related system calls.


2.Scheduling QueuesBelow is a list of the most common types of queues and their purpose.•

JobQueue - Each entering process goes into job queue. Processes in job queue reside on mass storage and awaits the allocation of main memory.•

Ready Queue - The set of all processes that are in main memory and are waiting for CPU time, are kept in ready queue.•

Waiting (Device) Queues - The set of processes waiting for allocation of certain I/O devices, are kept in waiting device queue.

3.A context switch is the computing process of storing and restoring the state (context) of a CPU such that multiple processes can share a single CPU resource. The context switch is an essential feature of a multitasking operating system. Context switches are usually computationally intensive and much of the design of operating systems is to optimize the use of context switches. A context switch can mean a register context switch, a task context switch, a thread context switch, or a process context switch. What constitutes the context is determined by the processor and the operating system.

the concept of Process

1. process state: the stage of execution that a process is in. It is these states which determine which processes are eligible to receive CPU time.
2. Process Control Block
   All of the information needed to keep track of a process when switching is kept in a data package called a process control block. The process control block typically contains:
   An ID number that identifies the process
   Pointers to the locations in the program and its data where processing last occurred
   Register contents
   States of various flags and switches
   Pointers to the upper and lower bounds of the memory required for the process
   A list of files opened by the process
   The priority of the process
   The status of all I/O devices needed by the process
   Each process has a status associated with it. Many processes consume no CPU time until they get some sort of input. For example, a process might be waiting for a keystroke from the user. While it is waiting for the keystroke, it uses no CPU time. While it's waiting, it is "suspended". When the keystroke arrives, the OS changes its status. When the status of the process changes, from pending to active, for example, or from suspended to running, the information in the process control block must be used like the data in any other program to direct execution of the task-switching portion of the operating system.
   This process swapping happens without direct user interference, and each process gets enough CPU cycles to accomplish its task in a reasonable amount of time. Trouble can begin if the user tries to have too many processes functioning at the same time. The operating system itself requires some CPU cycles to perform the saving and swapping of all the registers, queues and stacks of the application processes. If enough processes are started, and if the operating system hasn't been carefully designed, the system can begin to use the vast majority of its available CPU cycles to swap between processes rather than run processes. When this happens, it's called thrashing, and it usually requires some sort of direct user intervention to stop processes and bring order back to the system.
   One way that operating-system designers reduce the chance of thrashing is by reducing the need for new processes to perform various tasks. Some operating systems allow for a "process-lite," called a thread, that can deal with all the CPU-intensive work of a normal process, but generally does not deal with the various types of I/O and does not establish structures requiring the extensive process control block of a regular process. A process may start many threads or other processes, but a thread cannot start a process.
   So far, all the scheduling we've discussed has concerned a single CPU. In a system with two or more CPUs, the operating system must divide the workload among the CPUs, trying to balance the demands of the required processes with the available cycles on the different CPUs. Asymmetric operating systems use one CPU for their own needs and divide application processes among the remaining CPUs. Symmetric operating systems divide themselves among the various CPUs, balancing demand versus CPU availability even when the operating system itself is all that's running.
3. In computer science, a thread of execution results from a fork of a computer program into two or more concurrently running tasks. The implementation of threads and processes differs from one operating system to another, but in most cases, a thread is contained inside a process. Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.
   On a single processor, multithreading generally occurs by time-division multiplexing (as in multitasking): the processor switches between different threads. This context switching generally happens frequently enough that the user perceives the threads or tasks as running at the same time. On a multiprocessor or multi-core system, the threads or tasks will generally run at the same time, with each processor or core running a particular thread or task. Support for threads in programming languages varies: a number of languages simply do not support having more than one execution context inside the same program executing at the same time. Examples of such languages include Python, and OCaml, because the parallel support of their runtime support is limited by the use of a central lock, called "Global Interpreter Lock" in Python, "master lock" in Ocaml. Other languages may be limited because they use threads that are user threads, which are not visible to the kernel, and thus cannot be scheduled to run concurrently. On the other hand, kernel threads, which are visible to the kernel, can run concurrently.
   Many modern operating systems directly support both time-sliced and multiprocessor threading with a process scheduler. The kernel of an operating system allows programmers to manipulate threads via the system call interface. Some implementations are called a kernel thread, whereas a lightweight process (LWP) is a specific type of kernel thread that shares the same state and information.
   Programs can have user-space threads when threading with timers, signals, or other methods to interrupt their own execution, performing a sort of ad-hoc time-slicing.