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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 2373 Actions

    Problem Report Number 2373
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0653
    Raised 2004-05-14 03:44
    Updated 2004-05-16 15:15
    Published 2004-05-16 15:15
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSTH version 5.3.3
    Test Identification PTHR.os/rwlock/pthread_rwlock_wrlock 4
    PTHR.os/rwlock/pthread_rwlock_rdlock 6
    Specification System Interfaces and Headers Issue 5
    Location in Spec http://www.opennc.org/onlinepubs/007908799/xsh/pthread_rwlock_rdlock.html
    Problem Summary pthread_rwlock_wrlock 4 and pthread_rwlock_rdlock 6 expect behavior that
    is not specified in SUSv2
    Problem Text Using rdlock 6 as an example:

    rval = pthread_rwlock_wrlock( &T6_rwl );
    if ( rval == 0 )
    {
    rval = pthread_rwlock_rdlock( &T6_rwl );
    if ( rval != EDEADLK )
    {
    printf("pthread_rwlock_rdlock: Expected EDEADLK,
    got %dn", rval);
    nfails++;
    if ( rval == 0 )
    {
    (void) pthread_rwlock_unlock( &T6_rwl );
    }
    }

    The tests are trying to setup a situation where the calling thread owns
    the rwlock and then tries to lock it for reading. What should happen,
    according to the test, is EDEADLK should be returned. The problem is
    that for UNIX98 the behavior that the test assumes should happen is
    undefined in the standard.

    From the SUSv2 on pthread_rwlock_rdlock:

    "If a writer holds the lock, the calling thread will not acquire the
    read lock. If the read lock is not acquired, the calling thread blocks
    (that is, it does not return from the pthread_rwlock_rdlock() call)
    until it can acquire the lock. Results are undefined if the calling
    thread holds a write lock on rwlock at the time the call is made."

    So, a thread should block when it tries to acquire a lock that's already
    locked and the semantics are undefined when the thread is trying to grab
    a rdlock when it already has it as a write lock.

    Furthermore, the standards states that

    "The pthread_rwlock_rdlock() and pthread_rwlock_tryrdlock() functions
    may fail if:

    [EINVAL]
    The value specified by rwlock does not refer to an initialised
    read-write lock object.
    [EDEADLK]
    The current thread already owns the read-write lock for writing."

    The conditional word "may" highlights the fact that these error states
    are implementation dependent.

    Test Output 80|1571 0 06:18:21|TC End, scenario ref 1593-0
    10|1572
    /tset/PTHR.os/rwlock/pthread_rwlock_wrlock/T.pthread_rwlock_wrlock
    06:18:21|TC Start, scenario ref 1594-0
    15|1572 3.3-lite 5|TCM Start
    400|1572 4 1 06:18:21|IC Start
    200|1572 4 06:18:21|TP Start
    520|1572 4 00019062 1 1|If the implementation detects that the current
    thread already
    520|1572 4 00019062 1 2|owns the read-write lock object referenced by
    rwlock for520|1572 4 00019062 1 3|reading or writing: a call to
    pthread_rwlock_wrlock(rwlock)
    520|1572 4 00019062 1 4|shall fail and return EDEADLK.
    520|1572 4 00019062 1 5|XCAE ref: Component PTHREAD_RWLOCK_WRLOCK
    520|1572 4 00019062 1 6|Assertion 4(C)
    510|1572|system 0, errno = 145 (ETIMEDOUT): (alarm.c, 265): first
    TET_COND_TIMEDWAIT() failed in alrm_thr()
    220|1572 4 7 06:18:52|NORESULT (auto-generated by TCC)
    80|1572 1 06:18:52|TC End, scenario ref 1594-0

    10|1568
    /tset/PTHR.os/rwlock/pthread_rwlock_rdlock/T.pthread_rwlock_rdlock
    06:17:15|TC Start, scenario ref 1590-0
    15|1568 3.3-lite 8|TCM Start
    400|1568 1 1 06:17:15|IC Start
    400|1568 6 1 06:17:15|IC Start
    200|1568 6 06:17:15|TP Start
    520|1568 6 00019055 1 1|If the implementation detects that the current
    thread already
    520|1568 6 00019055 1 2|owns the read-write lock referenced by rwlock
    for writing:
    520|1568 6 00019055 1 3|a call to pthread_rwlock_rdlock(rwlock) shall
    fail
    520|1568 6 00019055 1 4|and return EDEADLK.
    520|1568 6 00019055 1 5|XCAE ref: Component PTHREAD_RWLOCK_RDLOCK
    520|1568 6 00019055 1 6|Assertion 6(C)
    510|1568|system 0, errno = 145 (ETIMEDOUT): (alarm.c, 265): first
    TET_COND_TIMEDWAIT() failed in alrm_thr()
    220|1568 6 7 06:17:47|NORESULT (auto-generated by TCC)
    80|1568 1 06:17:47|TC End, scenario ref 1590-0

    Review Information

    Review Type TSMA Review
    Start Date 2004-05-14 03:44
    Last Updated 2004-05-14 18:30
    Completed 2004-05-14 18:30
    Status Complete
    Review Recommendation Rejected (REJ)
    Review Response If the implementation does not detect these EDEADLK error conditions
    then the parameter VSTH_RWL_DEADLK should be set to "N" in tetexec.cfg.
    The tests will then give an Unsupported result.

    Review Type SA Review
    Start Date 2004-05-14 17:30
    Last Updated 2004-05-15 00:11
    Completed 2004-05-15 00:11
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion The TSMA has identified this PR as representing an error in test suite
    configuration. When this is correct the tests will give an acceptable
    result. For this reason the PR is rejected as a TSD

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority