Problem Report 0076 Details

Help Show help | Quick Search | Click here to view your privileges

This page provides all information on Problem Report 0076.

Report 0076 Actions

    Problem Report Number 0076
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.PX.0039
    Raised 2022-10-28 12:07
    Updated 2022-10-29 10:51
    Published 2022-10-29 10:51
    Product Standard PSE52 Realtime Controller 1003.1-2003 System
    Certification Program POSIX Certified by IEEE and The Open Group
    Test Suite VSTH-PSE version 5.5.17
    Test Identification /tset/PTHR.os/mutexattr_rt/pthread_mutexattr_setprotocol/T.pthread_mutexa
    ttr_setprotocol 9,11
    Specification PSE52 Realtime Controller 1003.1-2003 System Product Standard
    Location in Spec pthread_mutexattr_getprotocol() page
    Problem Summary Priority problem after a thread unlocks a mutex initialized by the
    PTHREAD_PRIO_PROTECT or PTHREAD_PRIO_INHERIT protocol
    Problem Text The purpose of test case 11 is "When a thread unlocks a mutex that
    has been initialized with the PTHREAD_PRIO_PROTECT protocol property,
    then it should not be subject to being moved to the end of the
    scheduling queue for its priority. " (It creates two threads, the
    scheduling policy of both threads is set to SCHED_FIFO, and the
    priority of both threads is x and x+1, then we call the low priority
    thread thread thread 0 and the high priority thread thread thread 1. In
    the execution function t11_t1 for thread 0 and thread 1, thread 0
    raises its priority to the same level as thread 1 by locking the mutex,
    while thread 0 (The priority of thread 0 is not lowered after the mutex
    is unlocked, so it is not preempted by thread 1.)

    The behavior in the test suite is not consistent with that described in
    the standard pthread_mutexattr_getprotocol() page.
    When a thread owns one or more mutexes initialized with the
    PTHREAD_PRIO_PROTECT protocol, it should execute at its priority or the
    highest priority limit of all mutexes owned by the thread and
    initialized with that attribute, so that when thread 0 unlocks the
    mutex, since this condition no longer applies, it should revert to
    executing at its own priority execution.

    However, according to the implementation of test case 11 in
    /tset/PTHR.os/mutexattr_rt/pthread_mutexattr_setprotocol/T
    pthread_mutexattr_setprotocol, we can infer that the test case
    considers that thread 0, when unlocking the mutex with
    PTHREAD_PRIO_PROTECT and lowering it to its original priority, should
    still have its upper priority at the top of the queue, because the test
    case does not allow thread 1 to preempt thread 0 when it unlocks the
    mutex (even though ad1 has a higher priority than thread 0 at this
    point), otherwise the test case will fail.

    The problem with test case 9 is similar.
    Test Output
    ***********************************************************************
    *

    /tset/PTHR.os/mutexattr_rt/pthread_mutexattr_setprotocol/T.pthread_mute
    x
    attr_setprotocol 9 Failed
    Test Description:
    If the _POSIX_THREAD_PRIO_INHERIT option is supported:
    when a thread unlocks a mutex that has been initialized with
    the
    PTHREAD_PRIO_INHERIT protocol attribute,
    then it shall not be subject to being moved to the tail of the
    scheduling
    queue at its priority.

    Test Information:
    Thread 2 exitval, expected 0, got 2


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


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

    /tset/PTHR.os/mutexattr_rt/pthread_mutexattr_setprotocol/T.pthread_mute
    x
    attr_setprotocol 11 Failed

    Test Description:
    If the _POSIX_THREAD_PRIO_PROTECT option is supported:
    when a thread unlocks a mutex that has been initialized with
    the
    PTHREAD_PRIO_PROTECT protocol attributes,
    then it shall not be subject to being moved to the tail of the
    scheduling
    queue at its priority.

    Test Information:
    Thread 2 exitval, expected 0, got 2


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

    Review Information

    Review Type TSMA Review
    Start Date 2022-10-28 12:07
    Last Updated 2022-10-28 10:34
    Completed 2022-10-28 10:34
    Status Complete
    Review Recommendation Test Suite Deficiency (TSD)
    Review Response This is accepted as a fault in the test suite.

    Review Type SA Review
    Start Date 2022-10-28 18:34
    Last Updated 2022-10-29 10:50
    Completed 2022-10-29 10:50
    Status Complete
    Review Resolution Test Suite Deficiency (TSD)
    Review Conclusion A test suite deficiency is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority