we should not need separate not_full and not-empty conditional variables. Also probably should avoid signaling if queue size wasn't empty or full before out change.
Great video! You explain really well. But in all 'truthi-ness' did you forget to share your implementation for lock_for_writing and unlock_for_writing? :D
Are we giving priority for readers here when many writers are waiting ?? Can you please clarify the below scenario ? Assuming single processor/core machine, we have many reader/writer threads in pool 1st writer thread is scheduled by OS scheduler & took a lock by pthread_mutex_lock(&writelock) in lock_for_writing(), thread made to sleep by OS scheduler then next 1st reader thread is scheduled and called lock_for_reading(), took lock by pthread_mutex_lock(&writelock), thread made to sleep by OS scheduler then assume we have 2nd writer thread scheduled waiting on pthread_mutex_lock(&writelock) in lock_for_writing(), thread made to sleep by OS scheduler Now if 1st Writer thread consumes data and calls unlock_for_writing() and releases pthread_mutex_unlock(&writelock), then OS scheduler can schedule any of 2nd Writer thread or 1st reader thread. Both are waiting on pthread_mutex_lock(&writelock). 1st writer thread may be scheduled and it successfully gets mutex writelock. This is forcing 1st reader to wait again. Then how we are guaranteeing that priority is given to 1st reader when 2nd writer is waiting ? In the wrost case all the readers may wait for writers.
In the read write lock you don’t prevent the writers starvation in case of a lot of reading threads
Very nice and understandable!! Great explanation of complex multithread concept!!
we should not need separate not_full and not-empty conditional variables.
Also probably should avoid signaling if queue size wasn't empty or full before out change.
Why not use two different locks, say p_peek and c_peek, for producers and consumers?
Great video! You explain really well. But in all 'truthi-ness' did you forget to share your implementation for lock_for_writing and unlock_for_writing? :D
Are we giving priority for readers here when many writers are waiting ?? Can you please clarify the below scenario ?
Assuming single processor/core machine, we have many reader/writer threads in pool
1st writer thread is scheduled by OS scheduler & took a lock by pthread_mutex_lock(&writelock) in lock_for_writing(), thread made to sleep by OS scheduler
then next 1st reader thread is scheduled and called lock_for_reading(), took lock by pthread_mutex_lock(&writelock), thread made to sleep by OS scheduler
then assume we have 2nd writer thread scheduled waiting on pthread_mutex_lock(&writelock) in lock_for_writing(), thread made to sleep by OS scheduler
Now if 1st Writer thread consumes data and calls unlock_for_writing() and releases pthread_mutex_unlock(&writelock), then OS scheduler can schedule any of 2nd Writer thread
or 1st reader thread. Both are waiting on pthread_mutex_lock(&writelock). 1st writer thread may be scheduled and it successfully gets mutex writelock. This is forcing 1st reader to wait again. Then how we are guaranteeing that priority is given to 1st reader when 2nd writer is waiting ? In the wrost case all the readers may wait for writers.
Do you have source code of reader-writer locks when writers dont't have starvation. if you have, can you share with me?
how to do it in bscscan pliz
how to do it in bscscan pliz