HI,

While looking into the test/code, I noticed something weird in the 
implementation of the rwlock read trylock on monarch.

int odp_rwlock_read_trylock(odp_rwlock_t *rwlock)
{
    uint32_t zero = 0;

    return odp_atomic_cas_acq_u32(&rwlock->cnt, &zero, (uint32_t)1);
}


This mean the trylock only succeed if no one was using the lock. But it will 
fail if someone was owning it *even* if it is a reader.
Is this something expected? If yes, it should probably be detailed in the API.


The lock implementation I wrote allows to get the lock if a reader already owns 
it. And causes the testsuite to deadlock:

    odp_rwlock_init(rw_lock);
    /* CU_ASSERT(odp_rwlock_is_locked(rw_lock) == 0); */

    odp_rwlock_read_lock(rw_lock); => Lock is owned in read

    rc = odp_rwlock_read_trylock(rw_lock); => Locked is owned a second time in 
read (rc = 1)
    CU_ASSERT(rc == 0);
    rc = odp_rwlock_write_trylock(rw_lock); => Expected failure
    CU_ASSERT(rc == 0);

    odp_rwlock_read_unlock(rw_lock); => Lock is still owned once.


So either the API should describe more accurately what are the expected 
success/failure case, or the test and implementation changed.

On a side note, the API explicitly says that reader have the priority on 
writers on rwlock. Is this really an API requirement?
Our rwlocks are the other way around to avoid the starvation issue. Do I need 
to change them ? Or is it OK with the API?

Nicolas

Reply via email to