summaryrefslogtreecommitdiffstats
path: root/lib/libc/regex/regex2.h
diff options
context:
space:
mode:
authoralc <alc@FreeBSD.org>2002-12-31 19:38:04 +0000
committeralc <alc@FreeBSD.org>2002-12-31 19:38:04 +0000
commit1842adc3403fdfdfa5e7a5e3aeedc2ad30a51fdc (patch)
treef466821885587addd092988b12cd19471611e5be /lib/libc/regex/regex2.h
parentf1a17aa7f4b46931b6a4109ec823885c76d6b614 (diff)
downloadFreeBSD-src-1842adc3403fdfdfa5e7a5e3aeedc2ad30a51fdc.zip
FreeBSD-src-1842adc3403fdfdfa5e7a5e3aeedc2ad30a51fdc.tar.gz
Implement a variant locking scheme for vm maps: Access to system maps
is now synchronized by a mutex, whereas access to user maps is still synchronized by a lockmgr()-based lock. Why? No single type of lock, including sx locks, meets the requirements of both types of vm map. Sometimes we sleep while holding the lock on a user map. Thus, a a mutex isn't appropriate. On the other hand, both lockmgr()-based and sx locks release Giant when a thread/process blocks during contention for a lock. This could lead to a race condition in a legacy driver (that relies on Giant for synchronization) if it attempts to kmem_malloc() and fails to immediately obtain the lock. Fortunately, we never sleep while holding a system map lock.
Diffstat (limited to 'lib/libc/regex/regex2.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud