Programming

From <<Advanced Programming in the Unix>> section 11.6, it says: Although implementations vary, readerwriter locks usually block additional readers if a lock is already held in read mode and a thread is blocked trying to acquire the lock in write mode. This prevents a constant stream of readers from starving waiting writers...
--is it wrong? because multiple threads can share read lock at same time.

I'm not certain, but (1) it depends on the implementation, and (2) it refers to the case where the lock is held by a reader AND is waiting to be acquired by a writer. If it's held by a reader and no writer is waiting, perhaps multiple readers can acquire it without problem.

Lock is required during either thread is wanting a write operation.
these may be the conditions:::::
1.)Read-Write,
2.)Write-Read,
3.)Write-Write.

You don't need a Lock in this condition
Read-Read.

Thanks!
I know the answer: the above description means under the condition that a read lock has already been held by a thread, if one thread tries to acquire a read lock, another one tries to acquire a write a lock, most implementation will give higher priority to the latter thread. That's why it says "This prevents a constant stream of readers from starving waiting writers"

Robin, it is slightly more complicated ....

From IEEE Std 1003.1-2008. pthread_rwlock_rdlock()

The pthread_rwlock_rdlock() function shall apply a read lock to the read-write lock referenced by rwlock. The calling thread acquires the read lock if a writer does not hold the lock and there are no writers blocked on the lock.

If the Thread Execution Scheduling option is supported, and the threads involved in the lock are executing with the scheduling policies SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the lock if a writer holds the lock or if writers of higher or equal priority are blocked on the lock; otherwise, the calling thread shall acquire the lock.

If the Thread Execution Scheduling option is supported, and the threads involved in the lock are executing with the SCHED_SPORADIC scheduling policy, the calling thread shall not acquire the lock if a writer holds the lock or if writers of higher or equal priority are blocked on the lock; otherwise, the calling thread shall acquire the lock.

If the Thread Execution Scheduling option is not supported, it is implementation-defined whether the calling thread acquires the lock when a writer does not hold the lock and there are writers blocked on the lock. If a writer holds the lock, the calling thread shall not acquire the read lock. If the read lock is not acquired, the calling thread shall block until it can acquire the lock. The calling thread may deadlock if at the time the call is made it holds a write lock.

Thanks for your specific explanation!