Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
2421 Discussions

upgrade_to_writer() starved by new readers

Black Belt

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.)

0 Kudos
0 Replies