semop.2: Recast discussion of blocking behavior in terms of threads

semop() blocks the calling thread, not the process.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2012-08-27 12:59:11 +02:00
parent 77ba6370c2
commit 352c778d01
1 changed files with 14 additions and 14 deletions

View File

@ -123,10 +123,10 @@ the semaphore value
.RI ( semval ).
Furthermore, if
.B SEM_UNDO
is specified for this operation, the system updates the process undo count
is specified for this operation, the system updates the undo count
.RI ( semadj )
for this semaphore.
This operation can always proceed\(emit never forces a process to wait.
This operation can always proceed\(emit never forces a thread to wait.
The calling process must have alter permission on the semaphore set.
.PP
If
@ -150,8 +150,8 @@ set to
is performed).
Otherwise
.I semzcnt
(the count of processes waiting until this semaphore's value becomes zero)
is incremented by one and the process sleeps until
(the count of threads waiting until this semaphore's value becomes zero)
is incremented by one and the thread sleeps until
one of the following occurs:
.IP \(bu 3
.I semval
@ -167,7 +167,7 @@ fails, with
set to
.BR EIDRM .
.IP \(bu
The calling process catches a signal:
The calling thread catches a signal:
the value of
.I semzcnt
is decremented and
@ -203,7 +203,7 @@ is subtracted from
.IR semval ,
and, if
.B SEM_UNDO
is specified for this operation, the system updates the process undo count
is specified for this operation, the system updates the undo count
.RI ( semadj )
for this semaphore.
If the absolute value of
@ -224,8 +224,8 @@ set to
is performed).
Otherwise
.I semncnt
(the counter of processes waiting for this semaphore's value to increase)
is incremented by one and the process sleeps until
(the counter of threads waiting for this semaphore's value to increase)
is incremented by one and the thread sleeps until
one of the following occurs:
.IP \(bu 3
.I semval
@ -239,7 +239,7 @@ is subtracted from
.I semval
and, if
.B SEM_UNDO
is specified for this operation, the system updates the process undo count
is specified for this operation, the system updates the undo count
.RI ( semadj )
for this semaphore.
.IP \(bu
@ -250,7 +250,7 @@ fails, with
set to
.BR EIDRM .
.IP \(bu
The calling process catches a signal:
The calling thread catches a signal:
the value of
.I semncnt
is decremented and
@ -273,7 +273,7 @@ On successful completion, the
.I sempid
value for each semaphore specified in the array pointed to by
.I sops
is set to the process ID of the calling process.
is set to the caller's process ID.
In addition, the
.I sem_otime
.\" and
@ -283,7 +283,7 @@ is set to the current time.
.BR semtimedop ()
behaves identically to
.BR semop ()
except that in those cases were the calling process would sleep,
except that in those cases were the calling thread would sleep,
the duration of that sleep is limited by the amount of elapsed
time specified by the
.I timespec
@ -365,7 +365,7 @@ of semaphores in the set.
The semaphore set was removed.
.TP
.B EINTR
While blocked in this system call, the process caught a signal; see
While blocked in this system call, the thread caught a signal; see
.BR signal (7).
.TP
.B EINVAL
@ -494,7 +494,7 @@ as far as possible (i.e., to zero) and allowing process
termination to proceed immediately.
In kernels 2.6.x, x <= 10, there is a bug that in some circumstances
prevents a process that is waiting for a semaphore value to become
prevents a thread that is waiting for a semaphore value to become
zero from being woken up when the value does actually become zero.
This bug is fixed in kernel 2.6.11.
.\" The bug report: