Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

ras_fork(9) [netbsd man page]

RAS(9)							   BSD Kernel Developer's Manual						    RAS(9)

NAME
ras_lookup, ras_fork, ras_purgeall -- restartable atomic sequences SYNOPSIS
#include <sys/types.h> #include <sys/proc.h> #include <sys/ras.h> void * ras_lookup(struct proc *p, void *addr); int ras_fork(struct proc *p1, struct proc *p2); int ras_purgeall(struct proc *p); DESCRIPTION
Restartable atomic sequences are user code sequences which are guaranteed to execute without preemption. This property is assured by check- ing the set of restartable atomic sequences registered for a process during cpu_switchto(9). If a process is found to have been preempted during a restartable sequence, then its execution is rolled-back to the start of the sequence by resetting its program counter saved in its process control block (PCB). The RAS functionality is provided by a combination of the machine-independent routines discussed in this page and a machine-dependent compo- nent in cpu_switchto(9). A port which supports restartable atomic sequences will define __HAVE_RAS in <machine/types.h> for machine-indepen- dent code to conditionally provide RAS support. A complicated side-effect of restartable atomic sequences is their interaction with the machine-dependent ptrace(2) support. Specifically, single-step traps and/or the emulation of single-stepping must carefully consider the effect on restartable atomic sequences. A general solution is to ignore these traps or disable them within restartable atomic sequences. FUNCTIONS
The functions which operate on restartable atomic sequences are: ras_lookup(p, addr) This function searches the registered restartable atomic sequences for process p which contain the user address addr. If the address addr is found within a RAS, then the restart address of the RAS is returned, otherwise -1 is returned. ras_fork(p1, p2) This function is used to copy all registered restartable atomic sequences for process p1 to process p2. It is primarily called from fork1(9) when the sequences are inherited from the parent by the child. ras_purgeall(p) This function is used to remove all registered restartable atomic sequences for process p. It is primarily used to remove all reg- istered restartable atomic sequences for a process during exec(3) and by rasctl(2). CODE REFERENCES
The RAS framework itself is implemented within the file sys/kern/kern_ras.c. Data structures and function prototypes for the framework are located in <sys/ras.h>. Machine-dependent portions are implemented within cpu_switchto(9) in the machine-dependent file sys/arch/<arch>/<arch>/locore.S. SEE ALSO
rasctl(2), cpu_switchto(9), fork1(9) Gregory McGarry, "An Implementation of User-level Restartable Atomic Sequences on the NetBSD Operating System", Proceedings of the FREENIX Track: 2003 USENIX Annual Technical Conference, USENIX Association, http://www.usenix.org/publications/library/proceedings/usenix03/tech/freenix03/full_papers/mcgarry/mcgarry.pdf, 311-322, June 9-14, 2003. HISTORY
The RAS functionality first appeared in NetBSD 2.0. BSD
April 17, 2010 BSD

Check Out this Related Man Page

ATOMIC_OPS(3)						   BSD Library Functions Manual 					     ATOMIC_OPS(3)

NAME
atomic_ops -- atomic memory operations SYNOPSIS
#include <sys/atomic.h> DESCRIPTION
The atomic_ops family of functions provide atomic memory operations. There are 7 classes of atomic memory operations available: atomic_add(3) These functions perform atomic addition. atomic_and(3) These functions perform atomic logical ``and''. atomic_cas(3) These functions perform atomic compare-and-swap. atomic_dec(3) These functions perform atomic decrement. atomic_inc(3) These functions perform atomic increment. atomic_or(3) These functions perform atomic logical ``or''. atomic_swap(3) These functions perform atomic swap. Synchronization Mechanisms Where the architecture does not provide hardware support for atomic compare and swap (CAS), atomicity is provided by a restartable sequence or by a spinlock. The chosen method is not ordinarily distinguishable by or visible to users of the interface. The following architectures can be assumed to provide CAS in hardware: alpha, amd64, i386, powerpc, powerpc64, sparc64. Scope and Restrictions If hardware CAS is available, the atomic operations are globally atomic: operations within a memory region shared between processes are guar- anteed to be performed atomically. If hardware CAS is not available, it may only be assumed that the operations are atomic with respect to threads in the same process. Additionally, if hardware CAS is not available, the atomic operations must not be used within a signal handler. Users of atomic memory operations should not make assumptions about how the memory access is performed (specifically, the width of the memory access). For this reason, applications making use of atomic memory operations should limit their use to regular memory. The results of using atomic memory operations on anything other than regular memory are undefined. Users of atomic memory operations should take care to modify any given memory location either entirely with atomic operations or entirely with some other synchronization mechanism. Intermixing of atomic operations with other synchronization mechanisms for the same memory loca- tion results in undefined behavior. Visibility and Ordering of Memory Accesses If hardware CAS is available, stores to the target memory location by an atomic operation will reach global visibility before the operation completes. If hardware CAS is not available, the store may not reach global visibility until some time after the atomic operation has com- pleted. However, in all cases a subsequent atomic operation on the same memory cell will be delayed until the result of any preceeding oper- ation has reached global visibility. Atomic operations are strongly ordered with respect to each other. The global visibility of other loads and stores before and after an atomic operation is undefined. Applications that require synchronization of loads and stores with respect to an atomic operation must use memory barriers. See membar_ops(3). Performance Because atomic memory operations require expensive synchronization at the hardware level, applications should take care to minimize their use. In certain cases, it may be more appropriate to use a mutex, especially if more than one memory location will be modified. SEE ALSO
atomic_add(3), atomic_and(3), atomic_cas(3), atomic_dec(3), atomic_inc(3), atomic_or(3), atomic_swap(3), membar_ops(3) HISTORY
The atomic_ops functions first appeared in NetBSD 5.0. BSD
April 14, 2010 BSD
Man Page