rmlock(9) 맨 페이지 - 윈디하나의 솔라나라

개요

섹션
맨 페이지 이름
검색(S)

rmlock(9)

Read-mostly locks allow shared access to protected data by multi‐
ple threads, or exclusive access by a single thread.  The threads
with  shared  access  are  known as since they only read the pro‐
tected data.  A thread with exclusive access is known as a  since
it  can modify protected data.  Read-mostly locks are designed to
be efficient for locks almost exclusively used  as  reader  locks
and  as  such  should  be  used  for  protecting data that rarely
changes.  Acquiring an exclusive lock after  the  lock  has  been
locked for shared access is an expensive operation.  Normal read-
mostly locks are similar to locks and follow the same lock order‐
ing  rules as locks.  Read-mostly locks have full priority propa‐
gation like mutexes.  Unlike read-mostly locks propagate priority
to both readers and writers.  This is implemented via the  struc‐
ture  argument supplied to and Readers can recurse if the lock is
initialized with the option; however, writers are  never  allowed
to  recurse.   Sleepable read-mostly locks are created by passing
to Unlike normal read-mostly locks, sleepable  read-mostly  locks
follow  the  same  lock ordering rules as locks.  Sleepable read-
mostly locks do not propagate priority to writers,  but  they  do
propagate  priority  to  readers.  Writers are permitted to sleep
while holding a read-mostly lock, but readers  are  not.   Unlike
other  sleepable locks such as locks, readers must use try opera‐
tions on other sleepable locks to avoid sleeping.  Initialize the
read-mostly lock The description is  used  solely  for  debugging
purposes.   This  function must be called before any other opera‐
tions on the lock.  Similar to initialize  the  read-mostly  lock
with a set of optional flags.  The arguments contains one or more
of  the  following  flags:  Instruct  to ignore this lock.  Allow
threads to recursively acquire shared locks for Create  a  sleep‐
able read-mostly lock.  If the kernel has been compiled with will
assert  that  the has not been initialized multiple times without
intervening calls to unless this option is specified.  Lock as  a
reader using to track read owners of a lock for priority propaga‐
tion.   This  data  structure is only used internally by and must
persist until has been called.  This data structure can be  allo‐
cated  on  the  stack  since readers cannot sleep.  If any thread
holds this lock exclusively, the current thread blocks,  and  its
priority  is propagated to the exclusive holder.  If the lock was
initialized with the option the function can be called  when  the
current  thread has already acquired reader access on Try to lock
as a reader.  will return 0 if the lock cannot be acquired  imme‐
diately;  otherwise,  the  lock  will  be acquired and a non-zero
value will be returned.  Note that may fail even while  the  lock
is  not  currently held by a writer.  If the lock was initialized
with the option, will succeed if the current thread  has  already
acquired  reader  access.   Lock  as  a writer.  If there are any
shared owners of the lock, the current thread blocks.  The  func‐
tion  cannot  be  called  recursively.   This function releases a
shared lock previously acquired by The argument  must  match  the
argument  used  for  acquiring  the shared lock This function re‐
leases an exclusive lock previously acquired  by  This  functions
destroys  a lock previously initialized with The lock must be un‐
locked.  This function returns a non-zero value  if  the  current
thread  owns  an  exclusive  lock on This function atomically re‐
leases while waiting for an event.  The lock must be  exclusively
locked.  For more details on the parameters to this function, see
This  function asserts that the lock is in the state specified by
If the assertions are not true and the kernel  is  compiled  with
and  the  kernel will panic.  Currently the following base asser‐
tions are supported: Assert that current thread  holds  either  a
shared  or  exclusive  lock of Assert that current thread holds a
shared lock of Assert that current thread holds an exclusive lock
of Assert that current thread holds neither a shared  nor  exclu‐
sive lock of In addition, one of the following optional flags may
be  specified  with or Assert that the current thread holds a re‐
cursive lock of Assert that the current thread does  not  hold  a
recursive  lock  of  These functions appeared in The facility was
written by This manual page was written by for rwlock  and  modi‐
fied to reflect rmlock by The implementation is currently not op‐
timized  for single processor systems.  can fail transiently even
when there is no writer, while another reader updates  the  state
on  the local CPU.  The implementation uses a single per CPU list
shared by all rmlocks in the system.  If rmlocks become  popular,
hashing  to multiple per CPU queues may be needed to speed up the
writer lock process.

























































맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.
RSS ATOM XHTML 5 CSS3