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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 2020 Actions

    Problem Report Number 2020
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0247
    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.2.1
    Test Identification PTHR.os/rwlock/pthread_rwlock_unlock 3
    Specification System Interfaces and Headers Issue 5
    Location in Spec See Problem Text
    Problem Summary PIN5TH.00003 According to System Interfaces and Headers, Issue 5: "If the call to the pthread_rwlock_unlock() function results in the read-write lock object becoming unlocked and there are multiple threads waiting...
    Problem Text

    According to System Interfaces and Headers, Issue 5:

    "If the call to the pthread_rwlock_unlock() function results in the
    read-write lock object becoming unlocked and there are multiple
    threads waiting to acquire the the read-write lock object for writing,
    the scheduling policy is used to determine which thread acquires the
    read-write lock object for writing"

    This part is clear. Since only one thread can hold the lock for
    writing, the thread with the highest priority should get the lock
    first.

    It further says:

    "If there are multiple threads waiting to acquire the read-write lock
    object for reading, the scheduling policy is used to determine the




    order in which the waiting threads acquire the read-write lock object
    for reading."

    The description of the behavior for acquisition for reading is
    identical to the description of acquisition for writing. Since many
    threads may hold a lock for reading at the same time, is it necessary
    to treat acquisition in the same manner as for writing? On a machine
    with multiple CPUs, why can't more than one thread waiting for the
    lock for reading be scheduled to run in parallel on seperate
    processors to acquire the lock, as long as scheduling is done by
    priority?

    Example, if there are 5 threads waiting on a 2 processor system, when
    the lock object is unlocked, the threads with the 2 highest priorities
    are scheduled to run, one on each processor. Even further, 5 threads
    waiting on a 10 processor system, all are scheduled to run on
    different processors. In both cases, since several (or all) threads
    are running at the same time, there is no way to determine the order
    the lock will be acquired.

    Also noted is in the Austin Group Draft, the seperate lines describing
    behavior for acquisition for writing and reading have been combined
    into one line, no longer differentiating between the two.

    "If there are threads blocked on the lock when it becomes available,
    the scheduling policy is used to determine which thread(s) shall
    acquire the lock. If the Thread Execution Scheduling option is
    supported, when threads executing with the scheduling policies
    SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC are waiting on the lock,
    they will acquire the lock in priority order when the lock becomes
    available."

    Test Output
    *****************************************************************************
    /tset/PTHR.os/rwlock/pthread_rwlock_unlock/T.pthread_rwlock_unlock 3 Failed

    Test Information:
    If _POSIX_THREAD_PRIORITY_SCHEDULING is defined,
    then when a call to pthread_rwlock_unlock(rwlock) results in the
    read-write lock object referenced by rwlock becoming unlocked and
    there are multiple threads waiting to acquire the lock for reading,
    then the scheduling policy is used to determine the order in which the
    waiting threads acquire the read-write lock object for reading.
    XCAE ref: Component PTHREAD_RWLOCK_UNLOCK
    Assertion 3(C)
    Unexpected lock acquisition order for thread 1
    Unexpected lock acquisition order for thread 2
    Unexpected lock acquisition order for thread 3
    Unexpected lock acquisition order for thread 4
    Unexpected lock acquisition order for thread 5
    Unexpected lock acquisition order for thread 6
    *****************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We agree that this appears to be a grey area and request it
    be forwarded to the working group for confirmation.


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


    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    The working group agreed that this is a grey area and that
    a permanent interpretation should be granted.


    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A Permanent Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority