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

More whitespace fixes to cleanup the previous commit.

Browse source
This commit is contained in:
John Baldwin 2004-08-16 22:05:05 +00:00
parent fd67a678b8
commit e13833ab9e
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=21974
1 changed files with 30 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -380,8 +380,9 @@
has value as a debugging aid since it exposes more race
conditions. It is especially useful on UP systems were many
races are hard to simulate otherwise. Thus, there is a
kernel option <literal>FULL_PREEMPTION</literal> to enable preemption for all kernel threads
that can be used for debugging purposes.</para>
kernel option <literal>FULL_PREEMPTION</literal> to enable
preemption for all kernel threads that can be used for
debugging purposes.</para>
</sect3>
</sect2>
@ -397,10 +398,10 @@
negative affects on per-CPU data since with the exception of
<varname>curthread</varname> and <varname>curpcb</varname> the
data can change whenever you migrate. Since you can
potentially migrate at any time this renders unprotected per-CPU data access
rather useless. Thus it is desirable to be able to disable
migration for sections of code that need per-CPU data to be
stable.</para>
potentially migrate at any time this renders unprotected
per-CPU data access rather useless. Thus it is desirable to be
able to disable migration for sections of code that need
per-CPU data to be stable.</para>
<para>Critical sections currently prevent migration since they
do not allow context switches. However, this may be too
@ -410,21 +411,23 @@
provided to allow the current thread to indicate that if it
preempted it should not migrate to another CPU.</para>
<para>This API is known as thread pinning and is provided by the scheduler. The API consists of two functions: <function>sched_pin</function> and <function>sched_unpin</function>. These functions manage a per-thread nesting count <varname>td_pinned</varname>. A thread is pinned
when its nesting count is greater than zero and a thread
starts off unpinned with a nesting count of zero. Each
scheduler implementation is required to ensure that pinned
threads are only executed on the CPU that they were executing
on when the <function>sched_pin</function> was first called.
Since the nesting count is only written to by
the thread itself and is only read by other threads when the
<para>This API is known as thread pinning and is provided by the
scheduler. The API consists of two functions:
<function>sched_pin</function> and
<function>sched_unpin</function>. These functions manage a
per-thread nesting count <varname>td_pinned</varname>. A
thread is pinned when its nesting count is greater than zero
and a thread starts off unpinned with a nesting count of zero.
Each scheduler implementation is required to ensure that
pinned threads are only executed on the CPU that they were
executing on when the <function>sched_pin</function> was first
called. Since the nesting count is only written to by the
thread itself and is only read by other threads when the
pinned thread is not executing but while
<varname>sched_lock</varname> is held, then
<varname>td_pinned</varname> does not need any locking.
The <function>sched_pin</function> function
increments the nesting count and
<function>sched_unpin</function> decrements the
<varname>td_pinned</varname> does not need any locking. The
<function>sched_pin</function> function increments the nesting
count and <function>sched_unpin</function> decrements the
nesting count. Due to the locking requirements specified
above, they will only operate on the current thread and thus
would not need to handle the case of making a thread
@ -500,13 +503,14 @@
reasons.</para>
<para>Usually, credentials are used in a read-only manner for access
control decisions, and in this case <structfield>td_ucred</structfield>
is generally preferred because it requires no locking. When a
process' credential is updated the <literal>proc</literal> lock
must be held across the check and update operations thus avoid
races. The process credential <structfield>p_ucred</structfield>
must be used for check and update operations to prevent
time-of-check, time-of-use races.</para>
control decisions, and in this case
<structfield>td_ucred</structfield> is generally preferred
because it requires no locking. When a process' credential is
updated the <literal>proc</literal> lock must be held across
the check and update operations thus avoid races. The process
credential <structfield>p_ucred</structfield> must be used for
check and update operations to prevent time-of-check,
time-of-use races.</para>
<para>If system call invocations will perform access control after
an update to the process credential, the value of