diff --git a/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml b/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml index 6040f4fc88..69cedba5ee 100644 --- a/en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml +++ b/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 - proctree_lock 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 inferior 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. + proctree_lock 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 + inferior 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. @@ -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 - exec 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. + exec 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. @@ -688,9 +689,11 @@ Select and Poll - The select and poll functions permit threads to block - waiting on events on file descriptors--most frequently, whether - or not the file descriptors are readable or writable. + The select and + poll functions permit threads to block + waiting on events on file descriptors--most frequently, + whether or not the file descriptors are readable or + writable. ... @@ -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 NULL if the object - is not registered, or points to a struct - sigio describing the registration. This field is - protected by a global mutex, sigio_lock. - Callers to SIGIO maintenance functions must pass in this field - by reference so that local register copies of - the field are not made when unprotected by the lock. + registration contains pointer field that is + NULL if the object is not registered, or + points to a struct sigio describing + the registration. This field is protected by a global mutex, + sigio_lock. Callers to SIGIO maintenance + functions must pass in this field by reference + so that local register copies of the field are not made when + unprotected by the lock. One struct sigio is allocated for each registered object associated with any process or process @@ -743,18 +747,19 @@ The sysctl 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 sysctl; 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. + for those variables. Currently, sysctl makes use of a single + global sx lock to serialize use of + sysctl; 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. - 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 sleepq_lookup 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 NULL. The sleepq_release - function unlocks the spin mutex associated with a given wait - channel. + it returns NULL. The + sleepq_release function unlocks the spin + mutex associated with a given wait channel. A thread is added to a sleep queue via the sleepq_add. This function accepts the @@ -840,18 +845,20 @@ sleepq_lock 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 - NULL. 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 - (SLEEPQ_INTERRUPTIBLE). Currently there are only two types of - sleep queues: traditional sleep queues managed via the + NULL. 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 (SLEEPQ_INTERRUPTIBLE). + Currently there are only two types of sleep queues: + traditional sleep queues managed via the msleep and wakeup - functions (SLEEPQ_MSLEEP) and condition variable sleep queues - (SLEEPQ_CONDVAR). The sleep queue type and lock pointer - argument are used solely for internal assertion checking. Code - that calls sleepq_add should explicitly - unlock any interlock protecting the wait channel after the - associated sleepqueue chain has been locked via + functions (SLEEPQ_MSLEEP) and condition + variable sleep queues (SLEEPQ_CONDVAR). + The sleep queue type and lock pointer argument are used solely + for internal assertion checking. Code that calls + sleepq_add should explicitly unlock any + interlock protecting the wait channel after the associated + sleepqueue chain has been locked via sleepq_lock and before blocking on the sleep queue via one of the waiting functions.