3.1. プロセル、ライトウエートプロセス、スレッド

Processという用語はいくらかの異なった意味をよく使われる。本ブックで、プロセスは実行におけるプログラムのインスタンスです。

The term “process” is often used with several different meanings. In this book, a process is an instance of a program in execution.

プロセスは人間のように：あれかが発生され、長く有意義な生活まはは短く有意義な生活があり、１以上の子供を発生し、最小的に死んでしまいます。小さい違いはプロセスの中でSexがない、各プロセスは父親または母親がいる。

Processes are like human beings: they are generated, they have a more or less significant life, they optionally generate one or more child processes, and eventually they die. A small difference is that sex is not really common among processes each process has just one parent.

カーネルの観点から、プロセスの目的はシステム資源（CPUタイム、メモリ、。。）が割り当てられるエンティティとして機能することです。

From the kernel’s point of view, the purpose of a process is to act as an entity to which system resources (CPU time, memory, etc.) are allocated.

プロセスが生成されるときそれは親とほとんど同じです。親のアドレススペス空き間の複写を受け入れ、親と同じコードで実行、プロセスを生成するシステムコールに続く次の命令に創める。だけれども、親子ほプログラムコード（Text)を含むページが共用できますが、それかには別々にコピーされたデータ（スタックとヒープ）があり、このデータは子に親が見えないメモリ位置へ変更されます。

When a process is created, it is almost identical to its parent. It receives a (logical) copy of the parent’s address space and executes the same code as the parent, beginning at the next instruction following the process creation system call. Although the parent and child may share the pages containing the program code (text), they have separate copies of the data (stack and heap), so that changes by the child to a memory location are invisible to the parent。

初期のUnixカーネルはこの簡単なモデルを使用しますが、近代のUnixシステムは使用ません。それかがマルチスレッドアプリケーションをサポート、ユーザプログラムが　アプリケーションデータ構造の大半を共有する　多くの相対的に独立している実行があります。そのようなシステムで一つのプロセルはいくらかのユーザスレッド（または簡単なスレッド）を含み、各スレッドは一つの実行流動のプレセルを代表します。現在、ほとんどのマルチスレッドアプリケーションがpThreadライブラリと呼ばれているセットのライブラリ機能を使って書かれている。

While earlier Unix kernels employed this simple model, modern Unix systems do not. They support multithreaded applications user programs having many relatively independent execution flows sharing a large portion of the application data structures. In such systems, a process is composed of several user threads (or simply threads), each of which represents an execution flow of the process. Nowadays, most multithreaded applications are written using standard sets of library functions called pthread (POSIX thread) libraries .

提供したの年嵩なバージョンのLinuxカーネルはマルチスレッドをサポートしません。カーネルの観点から、マルチスレッドアプリケーションは普通のプロセルみたいです。マルチプル実行流動のマルチスレッドアプリケーションがいつも手段のPOSIX-Complicant　pthread　ライブラリに全くユーザモード上で生成され、ハンドルされ、スケジュールされます。

Older versions of the Linux kernel offered no support for multithreaded applications. From the kernel point of view, a multithreaded application was just a normal process. The multiple execution flows of a multithreaded application were created, handled, and scheduled entirely in User Mode, usually by means of a POSIX-compliant pthread library.

しかし、実装のマルチスレッドアプリケーションのようにあまり満足しません。インスタンスにとって、一つのチェスプログラムは二つのスレッドを使うのを仮定：それかの一つがグラフィックチェス盤を制御し、移植のヒューマンフレーやーを持ち、移植のコンピューターを表示、その間　他のスレッドがじっくり次の移植のゲームを考えています。一番目のスレッドがヒューマン移植を持っているうち、二番目のスレッドが走り続くすべきである、そのように考えるタイムのヒューマンプレーヤーが利用されます。ところが、チェスプログラムはシングヅプロセルだけだったら、一番目のスレッドはユーザ行動を待つために簡単にブロッキングシステムコールを発行できません；別の方法で二番目のスレッドが妨げられます。その代わりに残っているプロセルが走られる可能を確実するために一番目のスレッドが複雑にする非ブロッキング技術を使用しなければなりません。

However, such an implementation of multithreaded applications is not very satisfactory. For instance, suppose a chess program uses two threads: one of them controls the graphical chessboard, waiting for the moves of the human player and showing the moves of the computer, while the other thread ponders the next move of the game. While the first thread waits for the human move, the second thread should run continuously, thus exploiting the thinking time of the human player. However, if the chess program is just a single process, the first thread cannot simply issue a blocking system call waiting for a user action; otherwise, the second thread is blocked as well. Instead, the first thread must employ sophisticated nonblocking techniques to ensure that the process runnable.

もっとよくマルチスレッドアプリケーションをサポートするためにLinuxはライトウエートプロセスを使用します。基本的に、二つのライトウエートプロセスの中でいくらのリソースを共有するかもしれない、たぶんアドレススペース、開いているフィルなど。それかの一つが共有したリソースを改変する時はいつも、片方がすぐに変化をみます。もちろん、共有したリソースへアクセスするとき二つのプロセスの中はシンクロナイズしなければなりません。

Linux uses lightweight processes to offer better support for multithreaded applications. Basically, two lightweight processes may share some resources, like the address space, the open files, and so on. Whenever one of them modifies a shared resource, the other immediately sees the change. Of course, the two processes must synchronize themselves when accessing the shared resource.

マルチスレッドアプリケーションを実装するために分かりやすい方法はライトウエートプロセスが各スレッドに仲間することである。この方法でスレッドは同じアドレススペースや、同じセットの開いているファイルなどを共有することで、同じセットのアプリケーションデータ構造にアクセスできます。同時に各スレッドがカーネルに独立してスケジュールさせられて、一つは残っているものが走る可能の間、永眠できます。

A straightforward way to implement multithreaded applications is to associate a lightweight process with each thread. In this way, the threads can access the same set of application data structures by simply sharing the same memory address space, the same set of open files, and so on; at the same time, each thread can be scheduled independently by the kernel so that one may sleep while another remains runnable.

POSIX-compliant　マルチスレッドアプリケーションはスレッドグルプをサポートするカーネルに一番良くハンドルされます。Linuxにおけてスレッドグルプは基本的にgetpid( )やkill( )やexit( )などがマルチスレッドを実装するセットのライトウエートプロセスのととです。本章、より遅くそれかを記述するつもりです。

POSIX-compliant multithreaded applications are best handled by kernels that support “thread groups .” In Linux a thread group is basically a set of lightweight processes that implement a multithreaded application and act as a whole with regards to some system calls such as getpid( ) , kill( ) , and _exit( ) . We are going to describe them at length later in this chapter.