Whitespace fixups.

svn path=/head/; revision=24567

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

@@ -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
+	<varname>proctree_lock</varname> sx lock and the per-process
-	the proc lock is easier as we are just checking to see who a
+	mutex.  Sometimes the proc lock is easier as we are just
-	parent of a process is that we already have locked.  However,
+	checking to see who a parent of a process is that we already
-	other places such as <function>inferior</function> need to
+	have locked.  However, other places such as
-	walk the tree of processes via parent pointers and locking
+	<function>inferior</function> need to walk the tree of
-	each process would be prohibitive as well as a pain to
+	processes via parent pointers and locking each process would
-	guarantee that the condition you are checking remains valid
+	be prohibitive as well as a pain to guarantee that the
-	for both the check and the actions taken as a result of the
+	condition you are checking remains valid for both the check
-	check.</para>
+	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
+	  <function>exec</function> on the Alpha needs to not be
-	  the actual context switch code.  Preemption is disabled for
+	  preempted as it supports the actual context switch code.
-	  these code sections by using a critical section.</para>
+	  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
+      <para>The <function>select</function> and
-	waiting on events on file descriptors--most frequently, whether
+	<function>poll</function> functions permit threads to block
-	or not the file descriptors are readable or writable.</para>
+	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
+	registration contains pointer field that is
-	is not registered, or points to a <structname>struct
+	<constant>NULL</constant> if the object is not registered, or
-	sigio</structname> describing the registration.  This field is
+	points to a <structname>struct sigio</structname> describing
-	protected by a global mutex, <varname>sigio_lock</varname>.
+	the registration.  This field is protected by a global mutex,
-	Callers to SIGIO maintenance functions must pass in this field
+	<varname>sigio_lock</varname>.  Callers to SIGIO maintenance
-	<quote>by reference</quote> so that local register copies of
+	functions must pass in this field <quote>by reference</quote>
-	the field are not made when unprotected by the lock.</para>
+	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:
+	using a system call.  At least two issues are raised in
-	first, the protection of the structures maintaining the
+	locking: first, the protection of the structures maintaining
-	namespace, and second, interactions with kernel variables and
+	the namespace, and second, interactions with kernel variables
-	functions that are accessed by the sysctl interface.  Since
+	and functions that are accessed by the sysctl interface.
-	sysctl permits the direct export (and modification) of
+	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
+	for those variables.  Currently, sysctl makes use of a single
-	single global sx lock to serialize use of <function>sysctl</function>; however, it
+	global sx lock to serialize use of
-	is assumed to operate under Giant and other protections are not
+	<function>sysctl</function>; however, it is assumed to operate
-	provided.  The remainder of this section speculates on locking
+	under Giant and other protections are not provided.  The
-	and semantic changes to sysctl.</para>
+	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>
+	it returns <constant>NULL</constant>.  The
-	function unlocks the spin mutex associated with a given wait
+	<function>sleepq_release</function> function unlocks the spin
-	channel.</para>
+	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
+	<constant>NULL</constant>.  The flags argument contains a type
-	the kind of sleep queue that the thread is being added to and
+	field that indicates the kind of sleep queue that the thread
-	a flag to indicate if the sleep is interruptible
+	is being added to and a flag to indicate if the sleep is
-	(<constant>SLEEPQ_INTERRUPTIBLE</constant>).  Currently there are only two types of
+	interruptible (<constant>SLEEPQ_INTERRUPTIBLE</constant>).
-	sleep queues: traditional sleep queues managed via the
+	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
+	functions (<constant>SLEEPQ_MSLEEP</constant>) and condition
-	(<constant>SLEEPQ_CONDVAR</constant>).  The sleep queue type and lock pointer
+	variable sleep queues (<constant>SLEEPQ_CONDVAR</constant>).
-	argument are used solely for internal assertion checking.  Code
+	The sleep queue type and lock pointer argument are used solely
-	that calls <function>sleepq_add</function> should explicitly
+	for internal assertion checking.  Code that calls
-	unlock any interlock protecting the wait channel after the
+	<function>sleepq_add</function> should explicitly unlock any
-	associated sleepqueue chain has been locked via
+	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>