login
Header Space

 
 

sem_overview(7)

July 5, 2007 - 2:21am
Submitted by Jeremy on July 5, 2007 - 2:21am.

INDEX

    NAME, DESCRIPTION, CONFORMING TO, NOTES, EXAMPLE, SEE ALSO, COLOPHON

    SEM_OVERVIEW 7 2006-03-25 "Linux" "Linux Programmer's Manual"

    NAME

    sem_overview - Overview of POSIX semaphores

    DESCRIPTION

    POSIX semaphores allow processes and threads to synchronize their actions.

    A semaphore is an integer whose value is never allowed to fall below zero. Two operations can be performed on semaphores: increment the semaphore value by one ( sem_post(3)); and decrement the semaphore value by one ( sem_wait(3)). If the value of a semaphore is currently zero, then a sem_wait(3) operation will block until the value becomes greater than zero.

    POSIX semaphores come in two forms: named semaphores and unnamed semaphores.

    Named semaphores

    A named semaphore is identified by a name of the form /somename. Two processes can operate on the same named semaphore by passing the same name to sem_open(3).

    The sem_open(3) function creates a new named semaphore or opens an existing named semaphore. After the semaphore has been opened, it can be operated on using sem_post(3) and sem_wait(3). When a process has finished using the semaphore, it can use sem_close(3) to close the semaphore. When all processes have finished using the semaphore, it can be removed from the system using sem_unlink(3).

    Unnamed semaphores (memory-based semaphores)
    An unnamed semaphore does not have a name. Instead the semaphore is placed in a region of memory that is shared between multiple threads (a "thread-shared semaphore") or processes (a "process-shared semaphore"). A thread-shared semaphore is placed in an area of memory shared between by the threads of a process, for example, a global variable. A process-shared semaphore must be placed in a shared memory region (e.g., a System V shared memory segment created using semget(2), or a POSIX shared memory object built created using shm_open(3)).

    Before being used, an unnamed semaphore must be initialized using sem_init(3). It can then be operated on using sem_post(3) and sem_wait(3). When the semaphore is no longer required, and before the memory in which it is located is deallocated, the semaphore should be destroyed using sem_destroy(3).

    The remainder of this section describes some specific details of the Linux implementation of POSIX semaphores.

    Versions

    Prior to kernel 2.6, Linux only supported unnamed, thread-shared semaphores. On a system with Linux 2.6 and a glibc that provides the NPTL threading implementation, a complete implementation of POSIX semaphores is provided.

    Persistence

    POSIX named semaphores have kernel persistence: if not removed by sem_unlink(3), a semaphore will exist until the system is shut down.

    Linking

    Programs using the POSIX semaphores API must be compiled with cc -lrt to link against the real-time library, librt.

    Accessing named semaphores via the file system

    On Linux, named semaphores are created in a virtual file system, normally mounted under /dev/shm, with names of the form sem.name.

    CONFORMING TO

    POSIX.1-2001.

    NOTES

    System V semaphores ( semget(2), semop(2), etc.) are an older semaphore API. POSIX semaphores provide a simpler, and better designed interface than System V semaphores; on the other hand POSIX semaphores are less widely available (especially on older systems) than System V semaphores.

    EXAMPLE

    An example of the use of various POSIX semaphore functions is shown in sem_wait(3).

    SEE ALSO

    sem_close(3), sem_destroy(3), sem_init(3), sem_getvalue(3), sem_open(3), sem_post(3), sem_unlink(3), sem_wait(3), pthreads(7)

    COLOPHON

    This page is part of release 2.79 of the Linux man-pages project. A description of the project, and information about reporting bugs, can be found at http://www.kernel.org/doc/man-pages/.
speck-geostationary