I do not quite understand how shared_mutex works in the 17th standard or in boost. Such a situation: several readers simultaneously capture this mutex, while old readers gradually release it, and other readers capture it, that is, for example, the capture of this mutex from several cycles with different periods of execution. Question: how in this case to the writer to write down the data protected by this mutex? It turns out that this mutex is constantly captured by some reader, and the writer does not receive it? Or is it a priority and when trying to capture it, it moves to the first positions in the queue to capture a mutex? How is this problem solved?
Jenssen jenssen
2,550 2 eleven 34
- And about him, by the way, that was not the way Meyers wrote, not Gunterot - that in the task of a reader / writer this could lead to the writer's starvation. But, as I recall, in principle, the task of the readers / writers is solved with the help of several ordinary mutexes without any special problems ... - Harry
- And, here, in the “Optimized C ++” Gunterota- In my experience, reader / writer mutexes lead to starvation of the writer's stream, unless reading is rarely performed; but in this case, the value of the read / write optimization is insignificant. As in the case of recursive mutexes, developers should have good reason to use this more complex mutex and, in general, choose a simpler and more predictable mutex. - Harry
- @Harry And how to solve this problem? I suggested about the high priority for the writer, perhaps there is a mechanism for pre-blocking the mutex by the writer, so that new readers cannot capture it before the writer, and the previous ones are finalizing their actions ... Probably, there are at least some developments on this task? - Jenssen
- Well, I, as you understand, did not work with him ... :) If you need a reader / writer implementation, then it is built on ordinary mutexes. - Harry
- I will assume that when a writer attempts to capture a mutex, the "writer wants to write" checkbox is set and readers can no longer be added, an exemption from the existing ones is expected, and then captured by the writer. - int3
|
1 answer
It turns out that this mutex is constantly captured by some reader, and the writer does not receive it?
It is worth reading some implementation details. On Linux, for example, POSIX RW-Lock is used: http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_rwlock_rdlock.html
Actually by the link above:
If you are a writer, it doesn’t hold it.
How to understand: if the writer tried to block the mutex, but there are active readers, then new readers will not be able to block the mutex, and when the last active person releases the mutex, the writer will be released and the mutex will now be exclusively his.
How it will be implemented: welcome to the implementation details. Fortunately, the source code for pthreads (more precisely, NPTL in glibc) is open. On Linux, synchronization primitives are based on the futex system call.
There is also GNU Pth - this is the implementation of the POSIX Threads interface in user space.
Well, if there is a lot of writing ... RW-lock is no good. Readers will starve. This primitive is just needed when reading is much more than writing.
Monah Tuk Monah Tuk
3,597 6 23
|