These two read together provide a balanced view.

ReaderWriterLock vs Monitor
http://www.interact-sw.co.uk/iangblog/2004/04/26/rwlockvsmonitor

When to use the ReaderWriterLock
https://www.interact-sw.co.uk/iangblog/2004/05/12/rwlock

cheers -ben

On Wed, Jan 13, 2016 at 6:27 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
> Hi Denis, all,
>
> I'm sorry for asking basic questions, but...
>
> I thought of this a little and I failed to see the advantage
> of using ReadWriteLock over monitor / mutex. What's the goal
> of ReadWriteLock? I mean - when should I use it rather than
> monitor / mutex? What practical advantage would it have?
>
> Best, Jan
>
>
> On Mon, 2016-01-04 at 18:39 +0100, Denis Kudriashov wrote:
>> Hi.
>>
>> I implemented small package ReadWriteLock http://smalltalkhub.com/mc/
>> Pharo/ReadWriteLock/main.
>>
>> Gofer it
>>�� �� �� ��smalltalkhubUser: 'Pharo' project: 'ReadWriteLock';
>>�� �� �� ��configurationOf: 'ReadWriteLock';
>>�� �� �� ��loadStable
>>
>> It is reentral read write lock which described in
>> https://en.wikipedia.org/wiki/Readers���writer_lock. From the article:
>>
>> > An ReadWriteLock allows concurrent access for read-only operations,
>> > while write operations require exclusive access. This means that
>> > multiple threads can read the data in parallel but an exclusive
>> > lock is needed for writing or modifying data. When a writer is
>> > writing the data, all other writers or readers will be blocked
>> > until the writer is finished writing.
>> Public API and Key Messages
>>
>> - lock := ReadWriteLock new
>> - lock criticalRead: aBlock
>> - lock criticalWrite: aBlock
>>
>> Implementation based on two semaphores and readers counter.
>>
>> Main difficulty is carefully handle process termination during
>> execution of critical sections. This problem described in
>> Semaphore>>critical: comment. Same approach is used here. But
>> synchronisation logic around two semaphores for reading and writing
>> complicates things very much. No simple way to decompose logic on
>> multiple methods because information about process interruption
>> become hidden.
>> From the Semaphore comment:
>> > The main trick is assignment right before we go into the wait
>> > primitive (which is not a real send and therefore not interruptable
>> > either). So after we can check that waiting is happen or not.
>> Tests are implemented only for lock scenarios. No tests for described
>> termination process cases. It is not really clear how to write it.
>> I will be appreciate if people review code. Maybe you will suggest
>> simplifications. It is always difficult to implement concurrent
>> code.
>>
>> Best regards,
>> Denis
>