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