pth.3

Linux下的中文输入法

.IP "\fBStandard \s-1POSIX\s0 Replacement \s-1API\s0\fR" 4
.IX Item "Standard POSIX Replacement API"
pth_nanosleep,
pth_usleep,
pth_sleep,
pth_waitpid,
pth_system,
pth_sigmask,
pth_sigwait,
pth_accept,
pth_connect,
pth_select,
pth_pselect,
pth_poll,
pth_read,
pth_readv,
pth_write,
pth_writev,
pth_pread,
pth_pwrite,
pth_recv,
pth_recvfrom,
pth_send,
pth_sendto.
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
.Vb 5
\&  ____  _   _
\& |  _ \e| |_| |__
\& | |_) | __| '_ \e         ``Only those who attempt
\& |  __/| |_| | | |          the absurd can achieve
\& |_|    \e__|_| |_|          the impossible.''
.Ve
.PP
\&\fBPth\fR is a very portable \s-1POSIX/ANSI\-C\s0 based library for Unix platforms which
provides non-preemptive priority-based scheduling for multiple threads of
execution (aka `multithreading') inside event-driven applications. All threads
run in the same address space of the application process, but each thread has
its own individual program counter, run-time stack, signal mask and \f(CW\*(C`errno\*(C'\fR
variable.
.PP
The thread scheduling itself is done in a cooperative way, i.e., the threads
are managed and dispatched by a priority\- and event-driven non-preemptive
scheduler. The intention is that this way both better portability and run-time
performance is achieved than with preemptive scheduling. The event facility
allows threads to wait until various types of internal and external events
occur, including pending I/O on file descriptors, asynchronous signals,
elapsed timers, pending I/O on message ports, thread and process termination,
and even results of customized callback functions.
.PP
\&\fBPth\fR also provides an optional emulation \s-1API\s0 for \s-1POSIX\s0.1c threads
(`Pthreads') which can be used for backward compatibility to existing
multithreaded applications. See \fBPth\fR's \fIpthread\fR\|(3) manual page for
details.
.Sh "Threading Background"
.IX Subsection "Threading Background"
When programming event-driven applications, usually servers, lots of
regular jobs and one-shot requests have to be processed in parallel.
To efficiently simulate this parallel processing on uniprocessor
machines, we use `multitasking' \*(-- that is, we have the application
ask the operating system to spawn multiple instances of itself. On
Unix, typically the kernel implements multitasking in a preemptive and
priority-based way through heavy-weight processes spawned with \fIfork\fR\|(2).
These processes usually do \fInot\fR share a common address space. Instead
they are clearly separated from each other, and are created by direct
cloning a process address space (although modern kernels use memory
segment mapping and copy-on-write semantics to avoid unnecessary copying
of physical memory).
.PP
The drawbacks are obvious: Sharing data between the processes is
complicated, and can usually only be done efficiently through shared
memory (but which itself is not very portable). Synchronization is
complicated because of the preemptive nature of the Unix scheduler
(one has to use \fIatomic\fR locks, etc). The machine's resources can be
exhausted very quickly when the server application has to serve too many
long-running requests (heavy\-weight processes cost memory). And when
each request spawns a sub-process to handle it, the server performance
and responsiveness is horrible (heavy\-weight processes cost time to
spawn). Finally, the server application doesn't scale very well with the
load because of these resource problems. In practice, lots of tricks
are usually used to overcome these problems \- ranging from pre-forked
sub-process pools to semi-serialized processing, etc.
.PP
One of the most elegant ways to solve these resource\- and data-sharing
problems is to have multiple \fIlight-weight\fR threads of execution
inside a single (heavy\-weight) process, i.e., to use \fImultithreading\fR.
Those \fIthreads\fR usually improve responsiveness and performance of the
application, often improve and simplify the internal program structure,
and most important, require less system resources than heavy-weight
processes. Threads are neither the optimal run-time facility for all
types of applications, nor can all applications benefit from them. But
at least event-driven server applications usually benefit greatly from
using threads.
.Sh "The World of Threading"
.IX Subsection "The World of Threading"
Even though lots of documents exists which describe and define the world
of threading, to understand \fBPth\fR, you need only basic knowledge about
threading. The following definitions of thread-related terms should at
least help you understand thread programming enough to allow you to use
\&\fBPth\fR.
.IP "\fBo\fR \fBprocess\fR vs. \fBthread\fR" 2
.IX Item "o process vs. thread"
A process on Unix systems consists of at least the following fundamental
ingredients: \fIvirtual memory table\fR, \fIprogram code\fR, \fIprogram
counter\fR, \fIheap memory\fR, \fIstack memory\fR, \fIstack pointer\fR, \fIfile
descriptor set\fR, \fIsignal table\fR. On every process switch, the kernel
saves and restores these ingredients for the individual processes. On
the other hand, a thread consists of only a private program counter,
stack memory, stack pointer and signal table. All other ingredients, in
particular the virtual memory, it shares with the other threads of the
same process.
.IP "\fBo\fR \fBkernel-space\fR vs. \fBuser-space\fR threading" 2
.IX Item "o kernel-space vs. user-space threading"
Threads on a Unix platform traditionally can be implemented either
inside kernel-space or user\-space. When threads are implemented by the
kernel, the thread context switches are performed by the kernel without
the application's knowledge. Similarly, when threads are implemented in
user\-space, the thread context switches are performed by an application
library, without the kernel's knowledge. There also are hybrid threading
approaches where, typically, a user-space library binds one or more
user-space threads to one or more kernel-space threads (there usually
called light-weight processes \- or in short LWPs).
.Sp
User-space threads are usually more portable and can perform faster
and cheaper context switches (for instance via \fIswapcontext\fR\|(2) or
\&\fIsetjmp\fR\|(3)/\fIlongjmp\fR\|(3)) than kernel based threads. On the other hand,
kernel-space threads can take advantage of multiprocessor machines and
don't have any inherent I/O blocking problems. Kernel-space threads are
usually scheduled in preemptive way side-by-side with the underlying
processes. User-space threads on the other hand use either preemptive or
non-preemptive scheduling.
.IP "\fBo\fR \fBpreemptive\fR vs. \fBnon-preemptive\fR thread scheduling" 2
.IX Item "o preemptive vs. non-preemptive thread scheduling"
In preemptive scheduling, the scheduler lets a thread execute until a
blocking situation occurs (usually a function call which would block)
or the assigned timeslice elapses. Then it detracts control from the
thread without a chance for the thread to object. This is usually
realized by interrupting the thread through a hardware interrupt
signal (for kernel-space threads) or a software interrupt signal (for
user-space threads), like \f(CW\*(C`SIGALRM\*(C'\fR or \f(CW\*(C`SIGVTALRM\*(C'\fR. In non-preemptive
scheduling, once a thread received control from the scheduler it keeps
it until either a blocking situation occurs (again a function call which
would block and instead switches back to the scheduler) or the thread
explicitly yields control back to the scheduler in a cooperative way.
.IP "\fBo\fR \fBconcurrency\fR vs. \fBparallelism\fR" 2
.IX Item "o concurrency vs. parallelism"
Concurrency exists when at least two threads are \fIin progress\fR at the
same time. Parallelism arises when at least two threads are \fIexecuting\fR
simultaneously. Real parallelism can be only achieved on multiprocessor
machines, of course. But one also usually speaks of parallelism or
\&\fIhigh concurrency\fR in the context of preemptive thread scheduling
and of \fIlow concurrency\fR in the context of non-preemptive thread
scheduling.
.IP "\fBo\fR \fBresponsiveness\fR" 2
.IX Item "o responsiveness"
The responsiveness of a system can be described by the user visible
delay until the system responses to an external request. When this delay
is small enough and the user doesn't recognize a noticeable delay,
the responsiveness of the system is considered good. When the user
recognizes or is even annoyed by the delay, the responsiveness of the
system is considered bad.
.IP "\fBo\fR \fBreentrant\fR, \fBthread-safe\fR and \fBasynchronous-safe\fR functions" 2
.IX Item "o reentrant, thread-safe and asynchronous-safe functions"
A reentrant function is one that behaves correctly if it is called
simultaneously by several threads and then also executes simultaneously.
Functions that access global state, such as memory or files, of course,
need to be carefully designed in order to be reentrant. Two traditional
approaches to solve these problems are caller-supplied states and
thread-specific data.
.Sp
Thread-safety is the avoidance of \fIdata races\fR, i.e., situations
in which data is set to either correct or incorrect value depending
upon the (unpredictable) order in which multiple threads access and
modify the data. So a function is thread-safe when it still behaves
semantically correct when called simultaneously by several threads (it
is not required that the functions also execute simultaneously). The
traditional approach to achieve thread-safety is to wrap a function body
with an internal mutual exclusion lock (aka `mutex'). As you should
recognize, reentrant is a stronger attribute than thread\-safe, because
it is harder to achieve and results especially in no run-time contention
between threads. So, a reentrant function is always thread\-safe, but not
vice versa.
.Sp
Additionally there is a related attribute for functions named
asynchronous\-safe, which comes into play in conjunction with signal
handlers. This is very related to the problem of reentrant functions. An
asynchronous-safe function is one that can be called safe and without
side-effects from within a signal handler context. Usually very few
functions are of this type, because an application is very restricted in
what it can perform from within a signal handler (especially what system
functions it is allowed to call). The reason mainly is, because only a
few system functions are officially declared by \s-1POSIX\s0 as guaranteed to
be asynchronous\-safe. Asynchronous-safe functions usually have to be
already reentrant.
.Sh "User-Space Threads"
.IX Subsection "User-Space Threads"
User-space threads can be implemented in various way. The two
traditional approaches are:
.IP "\fB1.\fR" 3
.IX Item "1."
\&\fBMatrix-based explicit dispatching between small units of execution:\fR
.Sp
Here the global procedures of the application are split into small
execution units (each is required to not run for more than a few
milliseconds) and those units are implemented by separate functions.
Then a global matrix is defined which describes the execution (and
perhaps even dependency) order of these functions. The main server
procedure then just dispatches between these units by calling one
function after each other controlled by this matrix. The threads are
created by more than one jump-trail through this matrix and by switching
between these jump-trails controlled by corresponding occurred events.
.Sp
This approach gives the best possible performance, because one can
fine-tune the threads of execution by adjusting the matrix, and the
scheduling is done explicitly by the application itself. It is also very
portable, because the matrix is just an ordinary data structure, and
functions are a standard feature of \s-1ANSI\s0 C.
.Sp
The disadvantage of this approach is that it is complicated to write
large applications with this approach, because in those applications
one quickly gets hundreds(!) of execution units and the control flow
inside such an application is very hard to understand (because it is
interrupted by function borders and one always has to remember the
global dispatching matrix to follow it). Additionally, all threads
operate on the same execution stack. Although this saves memory, it is
often nasty, because one cannot switch between threads in the middle of
a function. Thus the scheduling borders are the function borders.
.IP "\fB2.\fR" 3
.IX Item "2."
\&\fBContext-based implicit scheduling between threads of execution:\fR
.Sp
Here the idea is that one programs the application as with forked
processes, i.e., one spawns a thread of execution and this runs from the
begin to the end without an interrupted control flow. But the control
flow can be still interrupted \- even in the middle of a function.
Actually in a preemptive way, similar to what the kernel does for the
heavy-weight processes, i.e., every few milliseconds the user-space
scheduler switches between the threads of execution. But the thread
itself doesn't recognize this and usually (except for synchronization
issues) doesn't have to care about this.
.Sp
The advantage of this approach is that it's very easy to program,
because the control flow and context of a thread directly follows
a procedure without forced interrupts through function borders.
Additionally, the programming is very similar to a traditional and well
understood \fIfork\fR\|(2) based approach.