Hi.
I am going to bed now. Do you look at wikipedia link?
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