TDPL, shared data, and Phobos

[awishformore]

On 22/07/2010 01:49, Robert Jacques wrote:
> On Tue, 20 Jul 2010 15:41:31 -0400, Brian Palmer
> <d at brian.codekitchen.net> wrote:
>
>>> > It probably wasn't very clear from my simplified example, but I'm
>>> looking to create a shared-reader-one-writer scenario. If I declare
>>> MyValue synchronized, only one thread can be inside the get() method
>>> at a time, which defeats the shared-reader requirement. Imagine this
>>> is a much larger more complex data structure, where get() requires
>>> walking through multiple levels of a tree and a binary search at the
>>> last level.
>>> >
>>>
>>> Yup, I get it. But there is one point in it: write is not atomic
>>> operation in sense that get() might return half written data, right?
>>
>> No, that's why I want a read-write lock. Multiple threads can read the
>> data, but writes take an exclusive lock.
>>
>> http://en.wikipedia.org/wiki/Readers-writer_lock
>
> Have you tried core.sync.rwmutex? Also, please remember that CREW locks
> are not composable and can easily lead to dead-locks.

Afaik, the current rwmutex is a wrapper around two separate mutexes (one 
for readers, one for writers) and you have to decide whether readers or 
writers get precedence, meaning that ether all writers in the queue have 
to wait if just one reader has to write or all writers in the queue have 
to wait if there is a single reader comes up.

This is very unlike the behaviour I would like to see; I would expect 
readers and writers to be in the same queue, meaning the only difference 
between the rw and the normal mutex would be that all subsequent readers 
in the queue can read at the same time.

/Max