os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Add 2005 as a copyright year.

Browse source 
- Add markup to several variable, constant, and function names.
- Remove trailing () from marked up functions to be consistent.
- Split up a non-word into its two sub-words.
This commit is contained in:
John Baldwin 2005-05-12 21:23:08 +00:00
parent 03fb83b646
commit 5c855039bf
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=24565
1 changed files with 20 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

39
en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml
View file

@ -21,6 +21,7 @@
<copyright> <copyright>
<year>2002</year> <year>2002</year>
<year>2004</year> <year>2004</year>
<year>2005</year>
<holder>John Baldwin</holder> <holder>John Baldwin</holder>
<holder>Robert Watson</holder> <holder>Robert Watson</holder>
</copyright> </copyright>
@ -145,7 +146,7 @@
the locks. This can make writing rather expensive but can be the locks. This can make writing rather expensive but can be
useful when data is accessed in various ways. For example, useful when data is accessed in various ways. For example,
the parent process pointer is protected by both the the parent process pointer is protected by both the
proctree_lock sx lock and the per-process mutex. Sometimes <varname>proctree_lock</varname> sx lock and the per-process mutex. Sometimes
the proc lock is easier as we are just checking to see who a the proc lock is easier as we are just checking to see who a
parent of a process is that we already have locked. However, parent of a process is that we already have locked. However,
other places such as <function>inferior</function> need to other places such as <function>inferior</function> need to
@ -287,7 +288,7 @@
<para>Implementing full kernel preemption is very <para>Implementing full kernel preemption is very
straightforward: when you schedule a thread to be executed straightforward: when you schedule a thread to be executed
by putting it on a runqueue, you check to see if its by putting it on a run queue, you check to see if its
priority is higher than the currently executing thread. If priority is higher than the currently executing thread. If
so, you initiate a context switch to that thread.</para> so, you initiate a context switch to that thread.</para>
@ -298,7 +299,7 @@
thread may spin forever as the interrupted thread may never thread may spin forever as the interrupted thread may never
get a chance to execute. Also, some code such as the code get a chance to execute. Also, some code such as the code
to assign an address space number for a process during to assign an address space number for a process during
exec() on the Alpha needs to not be preempted as it supports <function>exec</function> on the Alpha needs to not be preempted as it supports
the actual context switch code. Preemption is disabled for the actual context switch code. Preemption is disabled for
these code sections by using a critical section.</para> these code sections by using a critical section.</para>
</sect3> </sect3>
@ -465,9 +466,9 @@
<sect2> <sect2>
<title>Callouts</title> <title>Callouts</title>
<para>The <function>timeout()</function> kernel facility permits <para>The <function>timeout</function> kernel facility permits
kernel services to register functions for execution as part kernel services to register functions for execution as part
of the <function>softclock()</function> software interrupt. of the <function>softclock</function> software interrupt.
Events are scheduled based on a desired number of clock Events are scheduled based on a desired number of clock
ticks, and callbacks to the consumer-provided function ticks, and callbacks to the consumer-provided function
will occur at approximately the right time.</para> will occur at approximately the right time.</para>
@ -475,17 +476,17 @@
<para>The global list of pending timeout events is protected <para>The global list of pending timeout events is protected
by a global spin mutex, <varname>callout_lock</varname>; by a global spin mutex, <varname>callout_lock</varname>;
all access to the timeout list must be performed with this all access to the timeout list must be performed with this
mutex held. When <function>softclock()</function> is mutex held. When <function>softclock</function> is
woken up, it scans the list of pending timeouts for those woken up, it scans the list of pending timeouts for those
that should fire. In order to avoid lock order reversal, that should fire. In order to avoid lock order reversal,
the <function>softclock</function> thread will release the the <function>softclock</function> thread will release the
<varname>callout_lock</varname> mutex when invoking the <varname>callout_lock</varname> mutex when invoking the
provided <function>timeout()</function> callback function. provided <function>timeout</function> callback function.
If the <constant>CALLOUT_MPSAFE</constant> flag was not set If the <constant>CALLOUT_MPSAFE</constant> flag was not set
during registration, then Giant will be grabbed before during registration, then Giant will be grabbed before
invoking the callout, and then released afterwards. The invoking the callout, and then released afterwards. The
<varname>callout_lock</varname> mutex will be re-grabbed <varname>callout_lock</varname> mutex will be re-grabbed
before proceeding. The <function>softclock()</function> before proceeding. The <function>softclock</function>
code is careful to leave the list in a consistent state code is careful to leave the list in a consistent state
while releasing the mutex. If <constant>DIAGNOSTIC</constant> while releasing the mutex. If <constant>DIAGNOSTIC</constant>
is enabled, then the time taken to execute each function is is enabled, then the time taken to execute each function is
@ -686,7 +687,7 @@
<sect2> <sect2>
<title>Select and Poll</title> <title>Select and Poll</title>
<para>The select() and poll() functions permit threads to block <para>The <function>select</function> and <function>poll</function> functions permit threads to block
waiting on events on file descriptors--most frequently, whether waiting on events on file descriptors--most frequently, whether
or not the file descriptors are readable or writable.</para> or not the file descriptors are readable or writable.</para>
@ -702,7 +703,7 @@
process or process group is permitted to register for SIGIO process or process group is permitted to register for SIGIO
from any given kernel object, and that process or group is from any given kernel object, and that process or group is
referred to as the owner. Each object supporting SIGIO referred to as the owner. Each object supporting SIGIO
registration contains pointer field that is NULL if the object registration contains pointer field that is <constant>NULL</constant> if the object
is not registered, or points to a <structname>struct is not registered, or points to a <structname>struct
sigio</structname> describing the registration. This field is sigio</structname> describing the registration. This field is
protected by a global mutex, <varname>sigio_lock</varname>. protected by a global mutex, <varname>sigio_lock</varname>.
@ -727,8 +728,8 @@
process group list. Developers implementing new kernel process group list. Developers implementing new kernel
objects supporting SIGIO will, in general, want to avoid objects supporting SIGIO will, in general, want to avoid
holding structure locks while invoking SIGIO supporting holding structure locks while invoking SIGIO supporting
functions, such as <function>fsetown()</function> functions, such as <function>fsetown</function>
or <function>funsetown()</function> to avoid or <function>funsetown</function> to avoid
defining a lock order between structure locks and the global defining a lock order between structure locks and the global
SIGIO lock. This is generally possible through use of an SIGIO lock. This is generally possible through use of an
elevated reference count on the structure, such as reliance elevated reference count on the structure, such as reliance
@ -739,7 +740,7 @@
<sect2> <sect2>
<title>Sysctl</title> <title>Sysctl</title>
<para>The <function>sysctl()</function> MIB service is invoked <para>The <function>sysctl</function> MIB service is invoked
from both within the kernel and from userland applications from both within the kernel and from userland applications
using a system call. At least two issues are raised in locking: using a system call. At least two issues are raised in locking:
first, the protection of the structures maintaining the first, the protection of the structures maintaining the
@ -749,7 +750,7 @@
kernel statistics and configuration parameters, the sysctl kernel statistics and configuration parameters, the sysctl
mechanism must become aware of appropriate locking semantics mechanism must become aware of appropriate locking semantics
for those variables. Currently, sysctl makes use of a for those variables. Currently, sysctl makes use of a
single global sx lock to serialize use of sysctl(); however, it single global sx lock to serialize use of <function>sysctl</function>; however, it
is assumed to operate under Giant and other protections are not is assumed to operate under Giant and other protections are not
provided. The remainder of this section speculates on locking provided. The remainder of this section speculates on locking
and semantic changes to sysctl.</para> and semantic changes to sysctl.</para>
@ -826,7 +827,7 @@
wait channel. The <function>sleepq_lookup</function> function wait channel. The <function>sleepq_lookup</function> function
looks in the hash table for the master sleep queue associated looks in the hash table for the master sleep queue associated
with a given wait channel. If no master sleep queue is found, with a given wait channel. If no master sleep queue is found,
it returns NULL. The <function>sleepq_release</function> it returns <constant>NULL</constant>. The <function>sleepq_release</function>
function unlocks the spin mutex associated with a given wait function unlocks the spin mutex associated with a given wait
channel.</para> channel.</para>
@ -838,14 +839,14 @@
<function>sleepq_lock</function> before this function is <function>sleepq_lock</function> before this function is
called. If no mutex protects the wait channel (or it is called. If no mutex protects the wait channel (or it is
protected by Giant), then the mutex pointer argument should be protected by Giant), then the mutex pointer argument should be
NULL. The flags argument contains a type field that indicates <constant>NULL</constant>. The flags argument contains a type field that indicates
the kind of sleep queue that the thread is being added to and the kind of sleep queue that the thread is being added to and
a flag to indicate if the sleep is interruptible a flag to indicate if the sleep is interruptible
(SLEEPQ_INTERRUPTIBLE). Currently there are only two types of (<constant>SLEEPQ_INTERRUPTIBLE</constant>). Currently there are only two types of
sleep queues: traditional sleep queues managed via the sleep queues: traditional sleep queues managed via the
<function>msleep</function> and <function>wakeup</function> <function>msleep</function> and <function>wakeup</function>
functions (SLEEPQ_MSLEEP) and condition variable sleep queues functions (<constant>SLEEPQ_MSLEEP</constant>) and condition variable sleep queues
(SLEEPQ_CONDVAR). The sleep queue type and lock pointer (<constant>SLEEPQ_CONDVAR</constant>). The sleep queue type and lock pointer
argument are used solely for internal assertion checking. Code argument are used solely for internal assertion checking. Code
that calls <function>sleepq_add</function> should explicitly that calls <function>sleepq_add</function> should explicitly
unlock any interlock protecting the wait channel after the unlock any interlock protecting the wait channel after the