Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1050 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 1050.

Report 1050 Actions

    Problem Report Number 1050
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0287
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSRT version 5.0.2
    Test Identification rt.os/mqueue/mq_receive 4
    Problem Summary PG4R.00017 It is not meaningful to use the scheduling policy of process scope threads to determine the order in which they contend for "system scope" semaphores and message queues.
    Problem Text
    This request addresses the following failures:

    /tset/rt.os/mqueue/mq_send/T.mq_send 5 Failed
    /tset/rt.os/mqueue/mq_receive/T.mq_receive 4 Failed
    /tset/rt.os/semaphores/sem_post/T.sem_post 3 Failed
    /tset/rt.os/semaphores/sem_post/T.sem_post 5 Failed

    These tests are attempting to verify that threads with process scope
    contention are scheduled relative to other process scope threads
    based upon their priority using inter-process semaphores and message
    queues as the blocking mechanism. Because inter-process semaphores
    and message queues are inter-process communication objects they have
    "system scope".

    It is not meaningful to use the scheduling policy of process scope
    threads to determine the order in which they contend for "system scope"
    semaphores and message queues. The accepted mechanisms for threads
    to control their order of execution are intra-process mutexes and
    semaphores, read/writer locks, and condition variables. Since the
    threads share the same address space within the process, they do not
    require inter-process semaphores and messge queues for communicating
    data.
    Test Output


    ************************************************************************
    /tset/rt.os/mqueue/mq_send/T.mq_send 5 Failed

    Test Description:
    If _POSIX_MESSAGE_PASSING and _POSIX_PRIORITY_SCHEDULING are defined
    or the implementation supports the mq_send() function as described in
    System Interfaces and Headers, Issue 5:
    When more than one thread is waiting to send a message to a message
    queue with calls to mq_send() the thread of the highest priority
    which has been waiting the longest shall be unblocked to send its
    message when space in the queue becomes available.

    Test Information:
    For SCHED_RR unblocked thread was incorrect, expected thread with priori
    ty 10 got 1
    For SCHED_FIFO unblocked thread was incorrect, expected thread 1 got 8
    mq_open() failed for "/vsrt_mqueue", errno = 24 (EMFILE)
    child process timed out


    ************************************************************************


    ************************************************************************
    /tset/rt.os/mqueue/mq_receive/T.mq_receive 4 Failed

    Test Description:
    If _POSIX_MESSAGE_PASSING and _POSIX_PRIORITY_SCHEDULING are defined
    or the implementation supports the mq_receive() function as described
    in System Interfaces and Headers, Issue 5:
    When more than one thread is waiting to receive a message to a
    message queue with calls to mq_receive() the thread of the highest
    priority which has been waiting the longest shall be selected to
    receive a message when one arrives.

    Test Information:
    For SCHED_FIFO unblocked thread was incorrect, expected thread with prio
    rity 10 got 8
    For SCHED_RR unblocked thread was incorrect, expected thread with priori
    ty 10 got 1
    mq_open() failed for "/vsrt_mqueue", errno = 24 (EMFILE)
    child process timed out


    ************************************************************************



    ************************************************************************
    /tset/rt.os/semaphores/sem_post/T.sem_post 3 Failed

    Test Description:
    If _POSIX_SEMAPHORES and _POSIX_PRIORITY_SCHEDULING are defined or
    the implementation supports the sem_post() function as described in
    System Interfaces and Headers, Issue 5:
    On a call to sem_post() when there are threads blocked waiting for
    the semaphore sem to become unlocked and the process scheduling
    policy is SCHED_FIFO the highest priority waiting thread shall be
    unblocked.

    Test Information:
    For SCHED_FIFO unblocked thread was incorrect, expected thread with prio
    rity 10 got 1


    ************************************************************************


    ************************************************************************
    /tset/rt.os/semaphores/sem_post/T.sem_post 5 Failed

    Test Description:
    If _POSIX_SEMAPHORES and _POSIX_PRIORITY_SCHEDULING are defined or
    the implementation supports the sem_post() function as described in
    System Interfaces and Headers, Issue 5:
    On a call to sem_post() when there are threads blocked waiting for
    the semaphore sem to become unlocked and the process scheduling
    policy is SCHED_RR the highest priority waiting thread shall be
    unblocked.

    Test Information:
    For SCHED_RR unblocked thread was incorrect, expected thread with priori
    ty 10 got 3


    ************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We recommend this request be refused.

    The argument here seems to be that the spec's thread scheduling
    requirements in the event of contention over semaphores or message
    queues are not meaningful for process scope threads and thus
    should not apply.

    Despite a thorough review we do not see anything in the spec which
    allows this reading.

    The requirements of the spec are defined specifically for these resources
    and are clear and unambiguous. Contention scope is not given any role
    in these requirements, much less that of determining whether the
    requirements apply to a thread. Rather, the requirements apply to all
    threads without any exceptions provided.

    Given the cut and dried nature of the specification we see no wiggle
    room possible for a TIN much less a TSD here.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority