Hi,

If I understand correctly:
- the Monitor only offer one kind of critical section that typically affects everyone equally,
- while with the new ReadWriteLock, the readers will be blocked only if a writer will acquire the writer critical section.

Cheers,
Doru

> On Jan 4, 2016, at 7:55 PM, Max Leske <maxleske@gmail.com> wrote:
>
> Hi Denis,
>
> How does your ReadWriteLock compare to Monitor? I was under the impression that what you describe could be done with a Monitor.
>
> Cheers,
> Max
>
>
>> On 04 Jan 2016, at 18:39, Denis Kudriashov <dionisiydk@gmail.com> 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
>

--
www.tudorgirba.com
www.feenk.com

���Live like you mean it."