Should a read-write mutex make it impossible for upgrade_to_writer() to be starved by new readers, even if there were some runtime overhead?
Currently, unless I'm mistaken, a spin_rw_mutex gives priority to aspiring writers in all circumstances (new reader and new writer in either order, and also upgrade_to_writer() against new readers). For queuing_rw_mutex, only arrival time counts for new readers vs. new writers (as may be expected), but an upgrade_to_writer() can be blocked for all eternity if readers individually only take a fraction of a second but happen to overlap (because of high contention, or in collusion for testing purposes). A reader_writer_lock doesn't do upgrade_to_writer(), and I haven't checked how it arbitrates between new readers and writers.
I would assume that progress is associated with writers, so that's a very strong argument to favour them. Or is this not an urgent problem (it would not be trivial to fix this)? Or not a problem at all?
(I am aware of release+acquire as a workaround, but then you always lose against all new readers already in the queue, even the ones after a new writer, and you always have to reacquire the protected state and redo any work you did based on it, even if you're currently the only one in the queue.)
