Browse Prior Art Database

System Singleton for UNIX

IP.com Disclosure Number: IPCOM000028223D
Original Publication Date: 2004-May-05
Included in the Prior Art Database: 2004-May-05
Document File: 5 page(s) / 106K

Publishing Venue

IBM

Abstract

Naming UNIX shared resources, such as shared memory segments or semaphores, in a robust yet portable way.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 26% of the total text.

Page 1 of 5

System Singleton for UNIX

Introduction A file system file can be used to store a reference to a shared resource, and a daemon process can be used to own the reference to the shared resource. Singletons are described in "Design Patterns" by Gamma et al.

    The name of the shared resource is used to identify a file on the system file which contains the id. of a shared memory segment containing a reference to the shared resource. A careful selection of data (described below) is included in the shared memory segment and the file to resolve ambiguities and races.

    The approach presented here takes a modular form with simple primitives to set and get the value of a singleton. Races to set the value are resolved by the singleton -- the loser gets a bad return code.

    The advantage over the solution of storing the shared resource reference directly in a file is that the approach presented here makes it possible to avoid using stale resource references which are created when the operating system restarts. An in-memory file system would also provide this, but is not portable.

    The advantage over the solution of using a daemon process is that the daemon can be killed, which opens up a timing window and consequent races. Also, communicating with a deamon is difficult to implement in a portable manner. Problem

    Shared memory segments and (System V) shared semaphores in UNIX* are created using an integer key. Such a key value needs to be selected carefully so as not to clash with keys already in use.

    Typically, the ftok API is used to generate a key from a file path. However, ftok is not guaranteed to give unique results for a given input file path: it can give different results at different times (e.g. on z/OS if the file system containing the file path is remounted) two distinct file paths can give the same key (e.g. if one file is a symbolic link to the other or, more likely, if the algorithm for calculating the key just happens to return the same value for distinct file paths, a documented limitation in Linux) So it may be necessary to try multiple key values (e.g. by varying the "project" parameter on ftok) before a new key is found.

    An alternative is to use the reserved key value IPC_PRIVATE to ensure that a new shared memory segment or shared semaphore is created. It is possible to share such segments and semaphores between processes, but this depends on a documented bug in Linux (see e.g. the man page for shmget) and may not be reliable in the future.

    After one process has created such a shared resource, we have to consider how others processes can find the shared resource. It is inconvenient for applications to use interprocess communication mechanisms to pass the key between the processes involved. Alternatives such as simply storing the key in the file system suffer from races when two processes try to create the shared resource concurrently and cause problems on system restart when the key in the file system may become stale and may be in u...