On 22/07/2010 01:49, Robert Jacques wrote:
On Tue, 20 Jul 2010 15:41:31 -0400, Brian Palmer
<d...@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
