svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
lockmgr(9)
The function is used to initialize a lock. It must be called be‐
fore any operation can be performed on a lock. Its arguments
are: A pointer to the lock to initialize. The priority passed to
The lock message. This is used for both debugging output and The
timeout value passed to The flags the lock is to be initialized
with: Allow recursive exclusive locks. Disable lock profiling
for this lock. Allow exclusive locks only. Instruct to ignore
this lock. should log messages about duplicate locks being ac‐
quired. Disable logging for this lock. Use during a sleep; oth‐
erwise, 0 is used. The function is used to destroy a lock, and
while it is called in a number of places in the kernel, it cur‐
rently does nothing. The and functions handle general locking
functionality within the kernel, including support for shared and
exclusive locks, and recursion. and are also able to upgrade and
downgrade locks. Their arguments are: A pointer to the lock to
manipulate. Flags indicating what action is to be taken. Ac‐
quire a shared lock. If an exclusive lock is currently held,
will be returned. Acquire an exclusive lock. If an exclusive
lock is already held, and is not set, the system will Downgrade
exclusive lock to a shared lock. Downgrading a shared lock is
not permitted. If an exclusive lock has been recursed, the sys‐
tem will Upgrade a shared lock to an exclusive lock. If this
call fails, the shared lock is lost, even if the flag is speci‐
fied. During the upgrade, the shared lock could be temporarily
dropped. Attempts to upgrade an exclusive lock will cause a Try
to upgrade a shared lock to an exclusive lock. The failure to
upgrade does not result in the dropping of the shared lock owner‐
ship. Release the lock. Releasing a lock that is not held can
cause a Wait for all activity on the lock to end, then mark it
decommissioned. This is used before freeing a lock that is part
of a piece of memory that is about to be freed. (As documented
in Fail if operation has slept. Do not allow the call to sleep.
This can be used to test the lock. Skip the checks for this in‐
stance. Allow recursion on an exclusive lock. For every lock
there must be a release. Unlock the interlock (which should be
locked already). Normally, postpones serving further shared re‐
quests for shared-locked lock if there is exclusive waiter, to
avoid exclusive lock starvation. But, if the thread requesting
the shared lock already owns a shared lockmgr lock, the request
is granted even in presence of the parallel exclusive lock re‐
quest, which is done to avoid deadlocks with recursive shared ac‐
quisition. The flag can only be used by code which requests
shared non-recursive lock. The flag allows exclusive requests to
preempt the current shared request even if the current thread
owns shared locks. This is safe since shared lock is guaranteed
to not recurse, and is used when thread is known to held unre‐
lated shared locks, to not cause unnecessary starvation. An ex‐
ample is locking in VFS when is already locked. An interlock mu‐
tex for controlling group access to the lock. If is specified,
and assume is currently owned and not recursed, and will return
it unlocked. See The and function work like and but accepting a
and on a per-instance basis. The specified values will override
the default ones, but this can still be used passing, respec‐
tively, and The function switches the owner from the current
thread to be if the lock is already held. The function prints
debugging information about the lock. It is used primarily by
functions. The function returns true if the lock is recursed, 0
otherwise. The function returns the status of the lock in rela‐
tion to the current thread. When compiled with and the function
tests for the assertions specified in and panics if they are not
met. One of the following assertions must be specified: Assert
that the current thread has either a shared or an exclusive lock
on the lock pointed to by the first argument. Assert that the
current thread has a shared lock on the lock pointed to by the
first argument. Assert that the current thread has an exclusive
lock on the lock pointed to by the first argument. Assert that
the current thread has no lock on the lock pointed to by the
first argument. In addition, one of the following optional as‐
sertions can be used with either an or assertion: Assert that the
current thread has a recursed lock on Assert that the current
thread does not have a recursed lock on The and functions return
0 on success and non-zero on failure. The function returns: An
exclusive lock is held by the current thread. An exclusive lock
is held by someone other than the current thread. A shared lock
is held. The lock is not held by anyone. and fail if: was re‐
quested and another thread had already requested a lock upgrade.
was set, and a sleep would have been required, or operation was
not able to upgrade the lock. was set and or did sleep. was set
in the lock priority, and a signal was delivered during a sleep.
Note the error below. was set in the lock priority, a signal was
delivered during a sleep, and the system call is to be restarted.
a non-zero timeout was given, and the timeout expired. If is
passed in the argument to or the must be held prior to calling or
and will be returned unlocked. Upgrade attempts that fail result
in the loss of the lock that is currently held. Also, it is in‐
valid to upgrade an exclusive lock, and a will be the result of
trying. This manual page was written by