CushionTheBlow (구 BluemoonSoft)

In software engineering, busy waiting or spinning is a technique in which a process repeatedly checks to see if a condition is true, such as waiting for keyboard input or waiting for a lock to become available. It can also be used to delay execution for some amount of time; this was necessary on old computers that had no method of waiting a specific length of time other than by repeating a useless loop a specific number of times, but on modern computers with clocks and different processor speeds, this form of time delay is often inaccurate and a sign of a naive attempt at programming. Spinning can be a valid strategy in certain special circumstances, most notably in the implementation of spinlocks within operating systems designed to run on SMP systems. In general, however, it is considered an anti-pattern and should be avoided, as the CPU time spent waiting could have been reassigned to another task.

Reference:
http://en.wikipedia.org/wiki/Busy_waiting

Hyper-threading (officially termed Hyper-Threading Technology or HTT) is an Intel-proprietary technology used to improve parallelization of computations performed on PC microprocessors via simultaneous multithreading. It is an improvement on super-threading. It debuted in U.S. Patent 4,847,755 (Gordon Morrison, et. al) and can be seen in use on the Intel Xeon processors and Pentium 4 processors. The technology improves processor performance under certain workloads by providing useful work for execution units that would otherwise be idle, for example during a cache miss. A Pentium 4 with Hyper-Threading enabled is treated by the operating system as two processors instead of one.

Hyper-threading relies on support in the operating system as well as the CPU. Conventional multiprocessor support is not enough to take advantage of hyper-threading. For example, even though Windows 2000 supports multiple CPUs, Intel does not recommend that hyper-threading be enabled under that operating system.

Reference:
http://en.wikipedia.org/wiki/Hyper_threading

Simultaneous multithreading, often abbreviated as SMT, is a technique for improving the overall efficiency of superscalar CPUs with Hardware multithreading. SMT permits multiple independent threads of execution to better utilize the resources provided by modern processor architectures.

Reference:
http://en.wikipedia.org/wiki/Simultaneous_multithreading

Symmetric multiprocessing, or SMP, is a multiprocessor computer architecture where two or more identical processors are connected to a single shared main memory. Most common multiprocessor systems today use an SMP architecture. In case of multi-core processors, the SMP architecture applies to the cores, treating them as separate processors.

SMP systems allow any processor to work on any task no matter where the data for that task are located in memory; with proper operating system support, SMP systems can easily move tasks between processors to balance the workload efficiently.

Reference:
http://en.wikipedia.org/wiki/Symmetric_multiprocessing

In modern computer operating systems, a process (or task) may wait on another process to complete its execution. In most systems, a parent process can create an independently executing child process. The parent process may then issue a wait system call, which suspends the execution of the parent process while the child executes. When the child process terminates, it returns an exit status to the operating system, which is then returned to the waiting parent process. The parent process then resumes execution.

Modern operating systems also provide system calls that allow process threads to create other threads and wait for them to terminate ("join" them) in a similar fashion.

An operating system may provide variations of the wait call that allow a process to wait for any of its children processes to exit, or to wait for a single specific child process (identified by its process-ID) to exit.

Some operating systems issue a signal (SIGCHLD) to the parent process when a child process terminates, notifying the parent process and allowing it to then retrieve the child process's exit status.

The exit status returned by a child process typically indicates whether the process terminated normally or abnormally. For normal termination, this status also includes the exit code (usually a small integer value) that the process returned to the system.

A child process that terminates but is never waited on by its parent becomes a zombie process. Such a process continues to exist as an entry in the system process table even though it is no longer an actively executing program. Such situations are typically handled with a special "reaper" process that locates zombies and retrieves their exit status, allowing the operating system to then deallocate their resources.

Similarly, a child process whose parent process terminates before it does becomes an orphan process. Such situations are typically handled with a special "root" (or "init") process, which is assigned as the new parent of a process when its parent process exits. This special process detects when an orphan process terminates and then retrieves its exit status, allowing the system to deallocate the terminated child process.

Reference:
http://en.wikipedia.org/wiki/Wait_%28operating_system%29

An orphan process is a computer process whose parent process has finished or terminated.

A process can become orphaned during remote invocation when the client process crashes after making a request of the server.

Orphans waste server resources and can potentially leave a server in trouble. However there are several solutions to the orphan process problem:

1. Extermination is the most commonly used technique; in this case the orphan is killed.
2. Reincarnation is a technique in which machines periodically try to locate the parents of any remote computations; at which point orphaned processes are killed.
3. Expiration is a technique where each process is allotted a certain amount of time to finish before being killed. If need be a process may "ask" for more time to finish before the allotted time expires.

A process can also be orphaned running on the same machine as its parent process. In a Unix-like operating system any orphaned process will be immediately adopted by the special init system process. This operation is called re-parenting and occurs automatically. Even though technically the process has the "init" process as its parent, it is still called an orphan process since the process which originally created it no longer exists.

Reference:
http://en.wikipedia.org/wiki/Orphan_process

In software engineering, a spinlock is a lock where the thread simply waits in a loop ("spins") repeatedly checking until the lock becomes available. As the thread remains active but isn't performing a useful task, the use of such a lock is a kind of busy waiting. Once acquired, spinlocks will usually be held until they are explicitly released, although in some implementations they may be automatically released if the thread blocks (aka "goes to sleep").

Spinlocks are efficient if threads are only likely to be blocked for a short period of time, as they avoid overhead from operating system process re-scheduling or context switching. For this reason, spinlocks are often used inside operating system kernels. However, spinlocks become wasteful if held for longer, both preventing other threads from running and requiring re-scheduling. The longer you hold the lock, the greater the risk that you will be interrupted by the O/S scheduler while holding it. If this happens, other threads will be left "spinning" (repeatedly trying to acquire the lock), despite the fact that you are not making progress towards releasing it. This is especially true on a single-processor system, where each waiting thread of the same priority is likely to waste its entire allocated timeslice ("quantum") spinning until the thread that holds the lock is finally re-scheduled.

Implementing spin locks correctly is difficult, because one must take account of the possibility of simultaneous access to the lock to prevent race conditions. Generally this is only possible with special assembly language instructions, such as atomic test-and-set operations, and cannot be implemented from high level languages like C.[1] On architectures without such operations, or if high-level language implementation is required, a non-atomic locking algorithm may be used, e.g. Peterson's algorithm. But note that such an implementation may require more memory than a spinlock, be slower to allow progress after unlocking, and may not be implementable in a high-level language if out-of-order execution is in use.

Reference:
http://en.wikipedia.org/wiki/Spin_lock

In computer engineering, out-of-order execution, OoOE, is a paradigm used in most high-performance microprocessors to make use of cycles that would otherwise be wasted by a certain type of costly delay. Most modern CPU designs include support for out of order execution.

Reference:
http://en.wikipedia.org/wiki/Out-of-order_execution

On Unix and Unix-like computer operating systems, a zombie process or defunct process is a process that has completed execution but still has an entry in the process table, this entry being still needed to allow the process that started the zombie process to read its exit status. The term zombie process derives from the common definition of zombie?an undead person. In the term's colorful metaphor, the child process has died but has not yet been reaped.

When a process ends, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process's entry in the process table remains. The parent can read the child's exit status by executing the wait system call, at which stage the zombie is removed. The wait call may be executed in sequential code, but it is commonly executed in a handler for the SIGCHLD signal, which the parent is sent whenever a child has died.

After the zombie is removed, its process ID and entry in the process table can then be reused. However, if a parent fails to call wait, the zombie will be left in the process table. In some situations this may be desirable, for example if the parent creates another child process it ensures that it will not be allocated the same process ID. As a special case, under Linux, if the parent explicitly ignores the SIGCHLD (sets the handler to SIG_IGN, rather than simply ignoring the signal by default), all child exit status information will be discarded and no zombie processes will be left.

A zombie process is not the same as an orphan process. An orphan process is a process that is still executing, but whose parent has died. They do not become zombie processes; instead, they are adopted by init (process ID 1), which waits on its children.

Zombies can be identified in the output from the Unix ps command by the presence of a "Z" in the STAT column. Zombies that exist for more than a short period of time typically indicate a bug in the parent program. As with other leaks, the presence of a few zombies isn't worrisome in itself, but may indicate a problem that would grow serious under heavier loads. Since there is no memory allocated to zombie processes except for the process table entry itself, the primary concern with many zombies is not running out of memory, but rather running out of process ID numbers.

To remove zombies from a system, the SIGCHLD signal can be sent to the parent manually, using the kill command. If the parent process still refuses to reap the zombie, the next step would be to remove the parent process. When a process loses its parent, init becomes its new parent. Init periodically executes the wait system call to reap any zombies with init as parent.

Reference:
http://en.wikipedia.org/wiki/Zombie_process

In computing, a system call is the mechanism used by an application program to request service from the operating system.

Reference:
http://en.wikipedia.org/wiki/System_call