semop() - Unix, Linux System Call

Unix - Home
Unix - Getting Started
Unix - File Management
Unix - Directories
Unix - File Permission
Unix - Environment
Unix - Basic Utilities
Unix - Pipes & Filters
Unix - Processes
Unix - Communication
Unix - The vi Editor
Unix - What is Shell?
Unix - Using Variables
Unix - Special Variables
Unix - Using Arrays
Unix - Basic Operators
Unix - Decision Making
Unix - Shell Loops
Unix - Loop Control
Unix - Shell Substitutions
Unix - Quoting Mechanisms
Unix - IO Redirections
Unix - Shell Functions
Unix - Manpage Help
Unix - Regular Expressions
Unix - File System Basics
Unix - User Administration
Unix - System Performance
Unix - System Logging
Unix - Signals and Traps
Unix - Useful Commands
Unix - Quick Guide
Unix - Builtin Functions
Unix - System Calls
Unix - Commands List
Unix Useful Resources
Computer Glossary
Who is Who
Copyright © 2014 by tutorialspoint
 
#include <sys/types.h>
 
#include <sys/ipc.h>
 
#include <sys/sem.h>


int semop(int semid, struct sembuf *sops, unsigned nsops); 

int semtimedop(int semid, struct sembuf *sops, unsigned nsops, struct timespec *timeout); 



unsigned short  semval;   /* semaphore value */
unsigned short  semzcnt;  /* # waiting for zero */
unsigned short  semncnt;  /* # waiting for increase */
pid_t           sempid;   /* process that did last op */









unsigned short sem_num;  /* semaphore number */
short          sem_op;   /* semaphore operation */
short          sem_flg;  /* operation flags */







The set of operations contained in
sops is performed
atomically, that is, the operations are performed at the same time, and only
if they can all be simultaneously performed.
The behaviour of the system call if not all operations can be
performed immediately depends on the presence of the
IPC_NOWAIT flag in the individual
sem_flg fields, as noted below.


Each operation is performed on the
sem_num-th semaphore of the semaphore set, where the first semaphore of the set
is numbered 0.
There are three types of operation, distinguished by the value of
sem_op. 

If
sem_op is a positive integer, the operation adds this value to
the semaphore value
(semval). Furthermore, if
SEM_UNDO is specified for this operation, the system updates the process undo count
(semadj) for this semaphore.
This operation can always proceed — it never forces a process to wait.
The calling process must have alter permission on the semaphore set.


If
sem_op is zero, the process must have read permission on the semaphore
set.
This is a "wait-for-zero" operation: if
semval is zero, the operation can immediately proceed.
Otherwise, if
IPC_NOWAIT is specified in
sem_flg, semop() fails with
errno set to
EAGAIN (and none of the operations in
sops is performed).
Otherwise
semzcnt (the count of processes waiting until this semaphore’s value becomes zero)
is incremented by one and the process sleeps until
one of the following occurs:


semtimedop() behaves identically to
semop() except that in those cases were the calling process would sleep,
the duration of that sleep is limited by the amount of elapsed
time specified by the
timespec structure whose address is passed in the
timeout parameter.  If the specified time limit has been reached,
semtimedop() fails with
errno set to
EAGAIN (and none of the operations in
sops is performed).
If the
timeout parameter is NULL,
then
semtimedop() behaves exactly like
semop(). 

semop() is never automatically restarted after being interrupted by a signal handler,
regardless of the setting of the
SA_RESTART flag when establishing a signal handler.


semadj is a per-process integer which is simply the (negative) count
of all semaphore operations performed specifying the
SEM_UNDO flag.
When a semaphore’s value is directly set using the
SETVAL or
SETALL request to
semctl(2),
the corresponding
semadj values in all processes are cleared.


The semval, sempid, semzcnt, and semnct values
for a semaphore can all be retrieved using appropriate
semctl(2)
calls.


The following limits on semaphore set resources affect the
semop() call:


semtimedop() first appeared in Linux 2.5.52,
and was subsequently backported into kernel 2.4.22.


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
zero from being woken up when the value does actually become zero.
This bug is fixed in kernel 2.6.11.