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

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 2090 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 2090.

Report 2090 Actions

    Problem Report Number 2090
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.1061
    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 VSTH version 5.1.4
    Test Identification PTHR.os/all/pthread_mutex_init 2
    Problem Summary TSD5TH.00068 This request concerns the following failures: pthread_mutex_init 2 pthread_mutex_lock 1 pthread_mutexattr_setprioceiling 2 pthread_mutexattr_setprotocol 6 In our implementation the sceduling allocatio...
    Problem Text

    This request concerns the following failures:

    pthread_mutex_init 2
    pthread_mutex_lock 1
    pthread_mutexattr_setprioceiling 2




    pthread_mutexattr_setprotocol 6

    In our implementation the sceduling allocation domain is always
    greater then one, for both uni-processor and multiprocessor machines.

    >From XSH5, Section 2.8.7, "Scheduling Allocation Domain" p. 51:

    For application threads with scheduling allocation domains of size
    greater than one, the rules defined for SCHED_FIFO and SCHED_RR
    are used in an implementation-defined manner.

    This means that for implementations whose allocation domains are
    greater than one there is no portable means to test the assertions
    above and the tests should give UNTESTED results.

    As an example consider the test for pthread_mutex_init 2, which can be
    described as follows:

    P1 is the priority of thread T1
    P2 is the priority of thread T2
    P3 is the priority of thread T3

    and P1 < P2 < P3

    T0 holds mutex M1.
    T1 holds mutex M2 (which is using the PTHREAD_PRIO_INHERIT protocol)
    T2 tries to aquire M1 but blocks because M1 is already held by T0
    T1 tries to aquire M1 but blocks because M1 is already held by T0
    Thread T3 tries to aquire M2 but blocks because M2 is already held by T1

    If priority inheritance is in force, the thread T1 should inherit the
    priority P3 from T3.

    At this point T0 drops the lock M1 and allows the threads T1 and T2 to
    race to update a global variable. This global variable will be set to a
    value to indicate which thread won the race. The test assumes that the
    higest priority thread will run first and win the race. If the
    scheduling allocation domain is one, this assumption is valid, because
    only a single thread can be run at a given time by the system.
    However, if the scheduling allocation domain is greater than one (as in
    our implementation) then both T1 and T2 will run concurrently. Which
    thread actually updates the global variable is then dependent upon how
    the threads access the memory being updated. Hence, this test cannot be
    used to verify prioirty inheritance on implementations with scheduling
    allocation domains greater than one.

    The other tests use similar strategies.

    The following is a comment from one of the tests:

    We have no way of directly assessing the priority with which a
    thread executes a particular section of code when the priority




    has been temporarily raised as a result of priority protection
    protocols because the access functions are required to NOT
    reflect such temporary adjustments in priority.

    We adopt a testing strategy which relies on the requirement that threads
    blocked on a mutex acquire it in priority order.

    Test Output

    ---

    10|140 /tset/PTHR.os/all/pthread_mutex_init/T.pthread_mutex_init 16:48:10|TC Start, scenario r
    ef 143-0
    200|140 2 16:48:11|TP Start
    520|140 2 00056572 1 1|A call to pthread_mutex_init(mutex, attr) initializes the mutex
    520|140 2 00056572 1 2|object referenced by mutex with the attributes specified by attr
    520|140 2 00056572 1 3|and returns 0 if successful.
    520|140 2 00056572 1 4|Posix Ref: Component PTHREAD_MUTEX_INIT
    520|140 2 00056572 1 5|Assertion 9945-1:1996 11.3.2.2-2(A)
    520|140 2 00056572 1 6|Testing the prioceiling attribute
    520|140 2 00056572 1 7|Testing the PTHREAD_PRIO_PROTECT protocol
    520|140 2 00056572 5 1|T2_first, expected 0, got 1
    520|140 2 00056572 5 2|Testing the PTHREAD_PRIO_INHERIT protocol
    520|140 2 00056572 11 1|T2_first, expected 0, got 1
    520|140 2 00056572 11 2|Testing the process shared attribute
    520|140 2 00056572 15 1|Testing the type attributes
    520|140 2 00056574 15 1|Testing the normal type attribute
    520|140 2 00056575 16 1|Testing the errorcheck type attribute
    520|140 2 00056576 17 1|Testing the recursive type attribute
    520|140 2 00056577 18 1|Testing the default type attribute
    220|140 2 1 16:48:18|FAIL

    ---

    0|142 /tset/PTHR.os/all/pthread_mutex_lock/T.pthread_mutex_lock 16:48:20|TC Start, scenario r
    ef 145-0
    15|142 3.2-lite 11|TCM Start
    400|142 1 1 16:48:20|IC Start
    200|142 1 16:48:20|TP Start
    520|142 1 00056582 1 1|If _POSIX_THREAD_PRIO_INHERIT is defined:
    520|142 1 00056582 1 2|when a thread makes a call to pthread_mutex_lock() on a mutex
    520|142 1 00056582 1 3|that was initialized with the PTHREAD_PRIO_INHERIT protocol
    520|142 1 00056582 1 4|attribute and the calling thread is blocked because the mutex
    520|142 1 00056582 1 5|is owned by another thread,
    520|142 1 00056582 1 6|then that owner thread shall inherit the priority level of
    520|142 1 00056582 1 7|the calling thread as long as it continues to own the mutex.
    520|142 1 00056582 1 8|The implementation shall update the priority of the owner
    520|142 1 00056582 1 9|thread to the maximum of its assigned priority and all its




    520|142 1 00056582 1 10|inherited priorities. Furthermore, if this owner thread itself
    520|142 1 00056582 1 11|becomes blocked on another mutex, the same priority inheritance
    520|142 1 00056582 1 12|effect shall be propagated to this other owner thread, in a
    520|142 1 00056582 1 13|recursive manner.
    520|142 1 00056582 1 14|Posix Ref: Component PTHREAD_MUTEX_LOCK
    520|142 1 00056582 1 15|Assertion 9945-1:1996 13.6.1.2-1(C)
    520|142 1 00056582 11 1|Thread 1 did not inherit the priority of thread 3
    520|142 1 00056582 11 2|Thread 4 did not inherit the priority of thread 1
    220|142 1 1 16:48:41|FAIL
    410|142 1 1 16:48:41|IC End

    ---

    10|345 /tset/PTHR.os/all/pthread_mutexattr_setprioceiling/T.pthread_mutexattr_setprioceiling 1
    4:44:36|TC Start, scenario ref 351-0
    200|345 2 14:44:37|TP Start
    520|345 2 000149242 1 1|If _POSIX_THREAD_PRIO_PROTECT is defined:
    520|345 2 000149242 1 2|the prioceiling attribute defines the priority
    520|345 2 000149242 1 3|ceiling of initialized mutexes, which is the minimum
    520|345 2 000149242 1 4|priority level at which the critical section guarded
    520|345 2 000149242 1 5|by the mutex is executed.
    520|345 2 000149242 1 6|Posix Ref: Component PTHREAD_MUTEXATTR_SETPRIOCEILING
    520|345 2 000149242 1 7|Assertion 9945-1:1996 13.6.1.2-2(C)
    220|345 2 1 14:44:51|FAIL

    ---

    10|164 /tset/PTHR.os/all/pthread_mutexattr_setprotocol/T.pthread_mutexattr_setprotocol 16:50:5
    7|TC Start, scenario ref 167-0
    400|164 6 1 16:50:57|IC Start
    200|164 6 16:50:57|TP Start
    520|164 6 00056633 1 1|If _POSIX_THREAD_PRIO_INHERIT is defined:
    520|164 6 00056633 1 2|when a thread is blocking higher priority threads
    520|164 6 00056633 1 3|because of owning one or more mutexes with the
    520|164 6 00056633 1 4|PTHREAD_PRIO_INHERIT protocol attribute,
    520|164 6 00056633 1 5|then it executes at the higher of either its priority
    520|164 6 00056633 1 6|or the priority of the highest priority thread waiting
    520|164 6 00056633 1 7|on any of the mutexes owned by this thread and
    520|164 6 00056633 1 8|initialized with this protocol.
    520|164 6 00056633 1 9|Posix Ref: Component PTHREAD_MUTEXATTR_SETPROTOCOL
    520|164 6 00056633 1 10|Assertion 9945-1:1996 13.6.1.2-6(C)
    220|164 6 1 16:51:03|FAIL

    ---

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    It is recommended that this request be circulated for review.


    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    This request is being sent for the 14 day anonymous review by
    the Base Working Group.


    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The Base Working group agrees that a test suite deficiency should
    be granted.


    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Test Suite Deficiency (TSD)
    Review Conclusion
    This is an agreed Test Suite Deficiency.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority