Another synchronization question...I hope you guys don't get annoyed ;)
Assume the following scenario: one central data structure (very large, so I don't really want to make it immutable and copy it around whenever a change occurs. I even don't want to keep multiple copies in memory), multiple reader threads that access that data structure read-only and one writer thread which keeps the data structure up to date in the background.
I currently synchronize all accesses to the data structure, which works just fine (no synchronization effects, no deadlocks). What I don't like about this approach is that most of the time I have a lot of reader threads active and the writer thread only active every now and then. Now it is completely unnecessary for the reader threads to wait for other reader threads to finish. They could easily access the data structure in parallel as long as the writer thread is not currently writing.
Is there a nice and elegant way to solve this kind of scenario?
EDIT: Thank you very much for the answers and links! Let me add just another short and related question: if the code executed within the reader's critical sections takes only a very short time (like just a hash table lookup), is it even worth considering implementing one of the techniques you describe or is the serialization effect of the locks not so bad in this case? Scalability and performance are very important. What do you think?
EDIT 2: I just looked into one implementation of a single writer / mulitple readers - lock and this implementation uses a monitor to synchronize some code in the WaitToRead method. Doesn't this cause the same serialization effect that I wanted to avoid in the first place? (Still assuming that the code to be synchronized is short and fast)
lock(); This means that if any other thread is reading or writing, stop here and wait until no other thread is reading or writing. Once the lock is granted, no other thread will be allowed to read or write (i.e. take a read or write lock) until the lock is released.
An SRW lock is the size of a pointer. The advantage is that it is fast to update the lock state.
This means that a stream of readers can subsequently lock all potential writers out and starve them. This is so, because after the first reader locks the resource, no writer can lock it, before it gets released. And it will only be released by the last reader.
To solve this situation, a writer should get exclusive access to an object i.e. when a writer is accessing the object, no reader or writer may access it. However, multiple readers can access the object at the same time.
There is a class for that purpose in RTL(sysutils) : TMultiReadExclusiveWriteSynchroniser
It is very easy to use. You don't need to strictly categorize your threads like reader or writer. Just call "BeginRead" or "BeginWrite" in a thread for starting a thread safe operation. Call "EndRead" or "EndWrite" for finishing the operation.
What you're looking for (and what vartec described) is called Reader(s)-Writer-Lock.
You can find some detailed notes on solving this problem at msdn magazine and an excerpt from Programming applications for MS windows.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With