sem_overview − overview of POSIX semaphores


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; that is, a null-terminated string of up to NAME_MAX−4 (i.e., 251) characters consisting of an initial slash, followed by one or more characters, none of which are slashes. 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 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 shmget(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.

Prior to kernel 2.6, Linux supported only 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.

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

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

Accessing named semaphores via the filesystem
On Linux, named semaphores are created in a virtual filesystem, normally mounted under /dev/shm, with names of the form sem.somename. (This is the reason that semaphore names are limited to NAME_MAX−4 rather than NAME_MAX characters.)

Since Linux 2.6.19, ACLs can be placed on files under this directory, to control object permissions on a per-user and per-group basis.




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.


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


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


This page is part of release 3.69 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at−pages/.

More Linux Commands

xmlcatalog(1) - Command line tool to parse and manipulate XM
xmlcatalog is a command line application allowing users to monitor and manipulate XML and SGML catalogs. It is included in libxml(3). Its functions can be invok

Tk_Screen(3) - retrieve information from Tk's local data str
Tk_WindowId and the other names listed above are all macros that return fields from Tks local data structure for tkwin. None of these macros requires any intera

Tk_FreeSavedOptions(3) - process configuration options......
These procedures handle most of the details of parsing configuration options such as those for Tk widgets. Given a description of what options are supported, th

open_memstream(3) - open memory as stream - Linux man page
The fmemopen() function opens a stream that permits the access specified by mode. The stream allows I/O to be performed on the string or memory buffer pointed t

pread(2) - read from or write to a file descriptor at a give
pread() reads up to count bytes from file descriptor fd at offset offset (from the start of the file) into the buffer starting at buf. The file offset is not ch

XkbGetDeviceLedInfo(3) - Query the indicator names, maps, an
XkbGetDeviceLedInfo queries the server for the desired LED information for the feedback specified by led_class and led_id for the X input extension device indic

curl_multi_init(3) - create a multi handle - Linux man page
This function returns a CURLM handle to be used as input to all the other multi-functions, sometimes referred to as a multi handle in some places in the documen

Time::localtime(3pm) - by-name interface to Perl's built-in
This modules default exports override the core localtime() function, replacing it with a version that returns Time::tm objects. This object has methods that ret

CPU_ALLOC(3) - macros for manipulating CPU sets (Man Page)
The cpu_set_t data structure represents a set of CPUs. CPU sets are used by sched_setaffinity(2) and similar interfaces. The cpu_set_t data type is implemented

XCreateSimpleWindow(3) - create windows and window attribute
XCreateSimpleWindow.3 - The XCreateWindow function creates an unmapped subwindow for a specified parent window, returns the window ID of the created window, and

setgroups32(2) - get/set list of supplementary group IDs....
getgroups() returns the supplementary group IDs of the calling process in list. The argument size should be set to the maximum number of items that can be store

send_easy_trap(3) - send TRAPs or INFORMs from a Net-SNMP MI
These three routines may be used to send traps from a MIB module within the Net-SNMP agent (including an AgentX subagent). send_easy_trap() sends an SNMPv1 trap

We can't live, work or learn in freedom unless the software we use is free.