Whitespace fixups.
This commit is contained in:
parent
cd44ed208a
commit
fa93dd8624
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=24567
1 changed files with 53 additions and 46 deletions
|
@ -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>
|
||||
|
||||
|
|
Loading…
Reference in a new issue