Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000628 [1003.1(2008)/Issue 7] System Interfaces Editorial Clarification Requested 2012-11-03 13:42 2020-03-23 10:39
Reporter weeks View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Nathan Weeks
Organization Iowa State University (HPC Group)
User Reference
Section semop
Page Number 1839
Line Number 0
Interp Status Approved
Final Accepted Text See Note: 0001429
Summary 0000628: subsequent execution of semaphore operations for a semop() of a thread suspended during semop() with sem_op == 0
Description The description of semop() states the following:

    3. If sem_op is 0 and the calling process has read permission, one of the
       following shall occur:

       ...

       * If semval is non-zero and (sem_flg &IPC_NOWAIT) is 0, semop() shall
         increment the semzcnt associated with the specified semaphore and
         suspend execution of the calling thread until one of the following
         occurs:

         - The value of semval becomes 0, at which time the value of semzcnt
           associated with the specified semaphore shall be decremented.

The last bullet does not specify if, after a semop() in another thread that
adjusts the semval, the semop() of the suspended thread can cause the semval
to be 0 with a sem_op < 0 that operates on the same sem_num and occurs before
the sem_op == 0 in the array of semaphore operations.

Implementations differ in this regard; specifically, the semop() of the
suspended thread can cause the action in the last bullet to occur (thus
resuming execution of the suspended thread) in RHEL 5.7 (with Linux kernel
2.6.18-274), and cannot in Solaris 10 u10, AIX 7.1, HP-UX 11i v2, and OS X
10.8.2.

This can be demonstrated by attached program (semop.c), which performs the
following actions:

1. A semaphore is created & initialized to 2.
2. A child process is fork()ed. The child process calls sleep(1) to allow the
   parent process to execute its semop first.
3. The parent process executes the same (decrease-by-1, wait-for-zero) array of
   semaphore operations, suspending since the entire array of operations
   cannot be completed.
4. The child process executes a decrease-by-1 semop (resulting in a semaphore
   value of 1), then exits.

On RHEL 5.7 (Linux kernel 2.6.18-274) the parent's semop() completes:
########################################
$ cc semop-posix.c
$ ./a.out
semid: 4161543
semop() completed
child process finished semop() (sem_op: -1)
########################################


On 10.8.2, Solaris 10 u10, AIX 7.1, HP-UX 11i v2, and OS X 10.8.2, the parent
process does not complete its semop() within the 5 seconds allowed by
alarm(5); e.g.:

########################################
$ ./a.out
semid: 2228224
child process finished semop() (sem_op: -1)
Alarm call
########################################

The Linux behavior is useful in that, with two semaphore operations (-N, 0), a
semop() can reliably wait for the value of a semaphore to be exactly N; on the
other implementations, this works as expected only if the semaphore value is N
when the array of semaphore operations is executed.
Desired Action Change:

    The value of semval becomes 0, at which time the value of semzcnt associated
    with the specified semaphore shall be decremented.

To:

    The value of semval becomes 0, at which time the value of semzcnt
    associated with the specified semaphore shall be decremented. It is
    unspecified whether this can be caused by a previous semaphore operation in
    the array of semaphore operations.
Tags issue8
Attached Files c file icon semop.c [^] (1,702 bytes) 2012-11-03 13:42
c file icon getxcnt.c [^] (1,863 bytes) 2012-11-19 14:19

- Relationships

-  Notes
(0001417)
msbrown (manager)
2012-11-07 16:31

Interpretation response
------------------------
The standard clearly states the time at which the operation shall occur and that it must be atomic , and conforming implementations must conform to this.

Rationale:
-------------
We believe the OS implementations listed as not completing in time are non-conforming to the specification.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
No change to the specification is required.
(0001423)
weeks (reporter)
2012-11-19 14:21
edited on: 2012-12-02 23:17

(Update: on the mailing list & in the Nov. 28 teleconference, Don Cragun stated that the Linux behavior in the following case---where semncnt and semzcnt effectively represent the number of semaphore operations waiting for semval to become greater-than-the-current-value or zero---doesn't match the intent of the designers of System V IPC, and that the and that OS X/AIX/HP-UX/Solaris behavior is correct)

So this information gets recorded for implementors who address this issue,
there is a related issue exemplified by the attached program getxcnt.c,
which does the following:

1. Creates a set of 2 semaphores
2. Initializes semaphore 0 <- 0 and semaphore 1 <- 1
3. Forks a child process that executes semaphore operations (-1, 0)
4. Checks semncnt for semaphore 0 and semzcnt for semaphore 1

If both semaphore operations in the array were executed atomically, the result
should look like that reported on Linux (kernel 2.6.18-274 from RHEL 5.7):

########################################
$ gcc getxcnt.c
$ ./a.out
semncnt 0: 1
semzcnt 1: 1
semop: Identifier removed
########################################

Other implementations tested (Solaris 10, AIX 7.1, HP-UX 11i v2, and
OS X 10.8.2) perform only the first semaphore operation in the array:

########################################
$ gcc getxcnt.c
$ ./a.out
semncnt 0: 1
semzcnt 1: 0
semop: Identifier removed
########################################

(0001424)
Don Cragun (manager)
2012-12-05 16:10
edited on: 2012-12-05 16:10

We had set Note: 0001417 as a resolution, but it has been pointed out that there is a deeper problem. A new resolution is being developed off-line.

(0001429)
Don Cragun (manager)
2012-12-12 16:23

Interpretation response
------------------------
The standard states on P1839, L58733-58735 that "the semop() function
shall perform atomically a user-defined array of semaphore operations"
but on P1839, L58759-58765 it says:
    The value of semval becomes greater than or equal to the absolute
    value of sem_op. When this occurs, the value of semncnt associated
    with the specified semaphore shall be decremented, the absolute
    value of sem_op shall be subtracted from semval and, if (sem_flg
    &SEM_UNDO) is non-zero, the absolute value of sem_op shall be added
    to the semadj value of the calling process for the specified
    semaphore.
and P1840, L58783-58784 it says:
    The value of semval becomes 0, at which time the value of semzcnt
    associated with the specified semaphore shall be decremented.
which require that the semaphore operations be acted on individually if
initial conditions cause the array of semaphore operations to block.
Conforming implementations must conform to these requirements. However,
concerns have been raised about this which are being referred to the
sponsor.

Rationale:
-------------
The stated requirements can only be met by an implementation if
each of the operations in the array of semaphore operations can be
completed successfully without blocking when semop() is called or
if there is only one semaphore operation in the array of semaphore
operations. The original intent of semop() was to atomically
complete the array of semaphore operations. If one of the operations
in the array causes semop() to block, the entire array of operations
should be attempted again when there is a change to the value of the
semaphore that caused the call to block.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
Change the entire description of processing the array of sempahore
operations in the DESCRIPTION section of semop() on P1839-1840,
L58747-58793 to the following:
   If all of the semaphore operations complete successfully, semop()
   shall return 0. If a semaphore operation fails or blocks, all
   changes to semadj and semval values performed by completed semaphore
   operations in the array before the operation that failed or blocked
   shall be undone before semop() returns or blocks, respectively. When
   a semaphore operation blocks, the change to semncnt or semzcnt

   indicating which semphore operation blocked shall not be undone until
   the operation unblocks.

   For each operation in the array of semaphore operations, the variable
   sem_op specifies one of three semaphore operations:
   1. If sem_op is a negative integer and the calling process has alter
       permission, one of the following shall occur:
       • If semval(see <sys/sem.h>) is greater than or equal to the
         absolute value of sem_op, the absolute value of sem_op shall be
         subtracted from semval. Also, if (sem_flg & SEM_UNDO) is
         non-zero, the absolute value of sem_op shall be added to the
         semadj value of the calling process for the specified
         semaphore. If this is not the last operation in the array of
         semaphore operations to be performed, processing shall continue
         with the next operation in the array.
       • If semval is less than the absolute value of sem_op and
         (sem_flg & IPC_NOWAIT) is non-zero, the operation shall fail
         with errno set to EAGAIN.
       • If semval is less than the absolute value of sem_op and
         (sem_flg & IPC_NOWAIT) is 0, semop() shall increment the
         semncnt associated with the specified semaphore and suspend
         execution of the calling thread (block) until one of the
         following conditions occurs:
         — The value of semval changes. When this occurs, the value of
           semncnt associated with the specified semaphore shall be
           decremented and the array of semaphore operations shall be
           reevaluated.
         — The semid for which the calling thread is awaiting action is
           removed from the system. When this occurs the operation
           shall fail with errno set to [EIDRM].
         — The calling thread receives a signal that is to be caught.
           When this occurs, the value of semncnt associated with the
           specified semaphore shall be decremented, and the calling
           thread shall resume execution in the manner prescribed in
           sigaction().
   2. If sem_op is a positive integer and the calling process has alter
       permission, the value of sem_op shall be added to semval and, if
       (sem_flg & SEM_UNDO) is non-zero, the value of sem_op shall be
       subtracted from the semadj value of the calling process for the
       specified semaphore. If this is not the last operation in the
       array of semaphore operations to be performed, processing shall
       continue with the next operation in the array.
   3. If sem_op is 0 and the calling process has read permission, one
       of the following shall occur:
       • If semval is 0, this is a successful operation. If this is not
         the last operation in the array of semaphore operations to be
         performed, processing shall continue with the next operation in
         the array.
       • If semval is non-zero and (sem_flg & IPC_NOWAIT) is non-zero,
         the operation shall fail with errno set to EAGAIN.
       • If semval is non-zero and (sem_flg & IPC_NOWAIT) is 0, semop()
         shall increment the semzcnt associated with the specified
         semaphore and suspend execution of the calling thread (block)
         until one of the following occurs:
         — The value of semval changes. When this occurs, the value of
           semzcnt associated with the specified semaphore shall be
           decremented and the array of semaphore operations shall be
           reevaluated.
         — The semid for which the calling thread is awaiting action is
           removed from the system. When this occurs, the operation
           shall fail with errno set to [EIDRM].
         — The calling thread receives a signal that is to be caught.
           When this occurs, the value of semzcnt associated with the
           specified semaphore shall be decremented, and the calling
           thread shall resume execution in the manner prescribed in
           sigaction().

   Upon successful completion of all of the semaphore operations
   specified in the array pointed to by sops the value of sempid for
   each semaphore specified in the array shall be set to the process ID
   of the calling process and the sem_otime timestamp associated with
   the semaphore set shall be set to the current time, as described in
   Section 2.7.1 (on page xxx).
(0001527)
ajosey (manager)
2013-03-29 08:07

Interpretation Proposed 29 Mar 2013
(0001577)
ajosey (manager)
2013-05-03 12:19

Interpretation approved 3 May 2013

- Issue History
Date Modified Username Field Change
2012-11-03 13:42 weeks New Issue
2012-11-03 13:42 weeks Status New => Under Review
2012-11-03 13:42 weeks Assigned To => ajosey
2012-11-03 13:42 weeks File Added: semop.c
2012-11-03 13:42 weeks Name => Nathan Weeks
2012-11-03 13:42 weeks Organization => Iowa State University (HPC Group)
2012-11-03 13:42 weeks Section => semop
2012-11-03 13:42 weeks Page Number => 0
2012-11-03 13:42 weeks Line Number => 0
2012-11-07 16:31 msbrown Note Added: 0001417
2012-11-07 16:32 msbrown Interp Status => Pending
2012-11-07 16:32 msbrown Final Accepted Text => Note: 0001417
2012-11-07 16:32 msbrown Status Under Review => Interpretation Required
2012-11-07 16:32 msbrown Resolution Open => Accepted
2012-11-07 16:33 msbrown Page Number 0 => 1839
2012-11-07 16:33 msbrown Resolution Accepted => Accepted As Marked
2012-11-19 14:19 weeks File Added: getxcnt.c
2012-11-19 14:21 weeks Note Added: 0001423
2012-11-19 14:21 weeks Note Edited: 0001423
2012-12-02 23:17 weeks Note Edited: 0001423
2012-12-05 16:10 Don Cragun Final Accepted Text Note: 0001417 =>
2012-12-05 16:10 Don Cragun Note Added: 0001424
2012-12-05 16:10 Don Cragun Status Interpretation Required => Under Review
2012-12-05 16:10 Don Cragun Resolution Accepted As Marked => Open
2012-12-05 16:10 Don Cragun Note Edited: 0001424
2012-12-12 16:23 Don Cragun Note Added: 0001429
2012-12-12 16:23 Don Cragun Status Under Review => Interpretation Required
2012-12-12 16:23 Don Cragun Resolution Open => Accepted As Marked
2012-12-12 16:24 Don Cragun Final Accepted Text => See Note: 0001429
2012-12-12 16:25 Don Cragun Tag Attached: issue8
2013-03-29 08:07 ajosey Interp Status Pending => Proposed
2013-03-29 08:07 ajosey Note Added: 0001527
2013-05-03 12:19 ajosey Interp Status Proposed => Approved
2013-05-03 12:19 ajosey Note Added: 0001577
2020-03-23 10:39 geoffclare Status Interpretation Required => Applied


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker