Browse Prior Art Database

Method for Initializing Semaphores that follow the UNIX System V Model

IP.com Disclosure Number: IPCOM000118558D
Original Publication Date: 1997-Mar-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 2 page(s) / 68K

Publishing Venue

IBM

Related People

Huras, MA: AUTHOR

Abstract

Semaphore implementations based on the UNIX* System V model provide no way to atomically initialize a semaphore when it is created. This can make it very difficult to apply these semaphores to some real-life applications.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method for Initializing Semaphores that follow the UNIX System V Model

      Semaphore implementations based on the UNIX* System V model
provide no way to atomically initialize a semaphore when it is
created.  This can make it very difficult to apply these semaphores
to some real-life applications.

      For example, consider a scenario where two processes both need
exclusive access to a resource.  A semaphore is used to protect the
resource, but it does not exist initially (i.e., after system boot),
so both processes detect its absence and try to create it (by calling
semget()).  Fortunately, semaphore creation is atomic, so one process
will succeed and the other will fail.  However, the semaphore is not
yet initialized, so the process that successfully created the
semaphore now issues a call to initialize its value to 0, indicating
that the resource is 'in use' (referred to as semctl(0)).  When it is
done with the resource, it will increment the semaphore value to 1
(semop(+1)).

      Meanwhile, the other process tries to wait until the resource
is free, by issuing a semaphore call (semop(-1)) that will
atomically:
  o  wait until the semaphore value is >0, then,
  o  decrement the semaphore value.

      If the timing is right, everything works fine; only one process
accesses the resource at a time.  However, if the timing is not
right, the following can happen:
  1.  The first process creates the semaphore (semget()).
  2.  At this point, the semaphore exists but is not initialized,
       i.e., its value could be anything.  Suppose it is 5, for
       the sake of argument.
  3.  The second process tries to create the semaphore, finds it
       is already created, so issues the semop(-1) call to wait
       until the resource is free.  This call succeeds immediately
       because the semaphore value is >0, so this process starts
       accessing the resource.
  4.  The first process, having successfully created the
       semaphore, 'believe...