Whitespace fixups.

This commit is contained in:
John Baldwin 2005-05-12 21:33:12 +00:00
parent cd44ed208a
commit fa93dd8624
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=24567

View file

@ -146,15 +146,15 @@
the locks. This can make writing rather expensive but can be
useful when data is accessed in various ways. For example,
the parent process pointer is protected by both the
<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
parent of a process is that we already have locked. However,
other places such as <function>inferior</function> need to
walk the tree of processes via parent pointers and locking
each process would be prohibitive as well as a pain to
guarantee that the condition you are checking remains valid
for both the check and the actions taken as a result of the
check.</para>
<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 parent of a process is that we already
have locked. However, other places such as
<function>inferior</function> need to walk the tree of
processes via parent pointers and locking each process would
be prohibitive as well as a pain to guarantee that the
condition you are checking remains valid for both the check
and the actions taken as a result of the check.</para>
</sect2>
<sect2>
@ -299,9 +299,10 @@
thread may spin forever as the interrupted thread may never
get a chance to execute. Also, some code such as the code
to assign an address space number for a process during
<function>exec</function> on the Alpha needs to not be preempted as it supports
the actual context switch code. Preemption is disabled for
these code sections by using a critical section.</para>
<function>exec</function> on the Alpha needs to not be
preempted as it supports the actual context switch code.
Preemption is disabled for these code sections by using a
critical section.</para>
</sect3>
<sect3>
@ -688,9 +689,11 @@
<sect2>
<title>Select and Poll</title>
<para>The <function>select</function> and <function>poll</function> functions permit threads to block
waiting on events on file descriptors--most frequently, whether
or not the file descriptors are readable or writable.</para>
<para>The <function>select</function> and
<function>poll</function> functions permit threads to block
waiting on events on file descriptors--most frequently,
whether or not the file descriptors are readable or
writable.</para>
<para>...</para>
</sect2>
@ -704,13 +707,14 @@
process or process group is permitted to register for SIGIO
from any given kernel object, and that process or group is
referred to as the owner. Each object supporting SIGIO
registration contains pointer field that is <constant>NULL</constant> if the object
is not registered, or points to a <structname>struct
sigio</structname> describing the registration. This field is
protected by a global mutex, <varname>sigio_lock</varname>.
Callers to SIGIO maintenance functions must pass in this field
<quote>by reference</quote> so that local register copies of
the field are not made when unprotected by the lock.</para>
registration contains pointer field that is
<constant>NULL</constant> if the object is not registered, or
points to a <structname>struct sigio</structname> describing
the registration. This field is protected by a global mutex,
<varname>sigio_lock</varname>. Callers to SIGIO maintenance
functions must pass in this field <quote>by reference</quote>
so that local register copies of the field are not made when
unprotected by the lock.</para>
<para>One <structname>struct sigio</structname> is allocated for
each registered object associated with any process or process
@ -743,18 +747,19 @@
<para>The <function>sysctl</function> MIB service is invoked
from both within the kernel and from userland applications
using a system call. At least two issues are raised in locking:
first, the protection of the structures maintaining the
namespace, and second, interactions with kernel variables and
functions that are accessed by the sysctl interface. Since
sysctl permits the direct export (and modification) of
using a system call. At least two issues are raised in
locking: first, the protection of the structures maintaining
the namespace, and second, interactions with kernel variables
and functions that are accessed by the sysctl interface.
Since sysctl permits the direct export (and modification) of
kernel statistics and configuration parameters, the sysctl
mechanism must become aware of appropriate locking semantics
for those variables. Currently, sysctl makes use of a
single global sx lock to serialize use of <function>sysctl</function>; however, it
is assumed to operate under Giant and other protections are not
provided. The remainder of this section speculates on locking
and semantic changes to sysctl.</para>
for those variables. Currently, sysctl makes use of a single
global sx lock to serialize use of
<function>sysctl</function>; however, it is assumed to operate
under Giant and other protections are not provided. The
remainder of this section speculates on locking and semantic
changes to sysctl.</para>
<para>- Need to change the order of operations for sysctl's that
update values from read old, copyin and copyout, write new to
@ -828,9 +833,9 @@
wait channel. The <function>sleepq_lookup</function> function
looks in the hash table for the master sleep queue associated
with a given wait channel. If no master sleep queue is found,
it returns <constant>NULL</constant>. The <function>sleepq_release</function>
function unlocks the spin mutex associated with a given wait
channel.</para>
it returns <constant>NULL</constant>. The
<function>sleepq_release</function> function unlocks the spin
mutex associated with a given wait channel.</para>
<para>A thread is added to a sleep queue via the
<function>sleepq_add</function>. This function accepts the
@ -840,18 +845,20 @@
<function>sleepq_lock</function> before this function is
called. If no mutex protects the wait channel (or it is
protected by Giant), then the mutex pointer argument should be
<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
a flag to indicate if the sleep is interruptible
(<constant>SLEEPQ_INTERRUPTIBLE</constant>). Currently there are only two types of
sleep queues: traditional sleep queues managed via the
<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 a flag to indicate if the sleep is
interruptible (<constant>SLEEPQ_INTERRUPTIBLE</constant>).
Currently there are only two types of sleep queues:
traditional sleep queues managed via the
<function>msleep</function> and <function>wakeup</function>
functions (<constant>SLEEPQ_MSLEEP</constant>) and condition variable sleep queues
(<constant>SLEEPQ_CONDVAR</constant>). The sleep queue type and lock pointer
argument are used solely for internal assertion checking. Code
that calls <function>sleepq_add</function> should explicitly
unlock any interlock protecting the wait channel after the
associated sleepqueue chain has been locked via
functions (<constant>SLEEPQ_MSLEEP</constant>) and condition
variable sleep queues (<constant>SLEEPQ_CONDVAR</constant>).
The sleep queue type and lock pointer argument are used solely
for internal assertion checking. Code that calls
<function>sleepq_add</function> should explicitly unlock any
interlock protecting the wait channel after the associated
sleepqueue chain has been locked via
<function>sleepq_lock</function> and before blocking on the
sleep queue via one of the waiting functions.</para>