https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102962
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Marco Mengelkoch from comment #2) > I would understand if just the order is different or if one is much faster > than the other. We have two completely different implementations of std::shared_mutex, one based on pthread_rwlock_t and one based on std::condition_variable. That they have different ordering and queueing behaviour is not surprising. > While I would prefer the behavior of windows, it seems that the > documentation doesn't look accurate for windows > > > // https://en.cppreference.com/w/cpp/thread/shared_mutex > > If one thread has acquired the shared lock (through lock_shared, > > try_lock_shared), no other thread can acquire the exclusive lock, but can > > acquire the shared lock. If we read "but can acquire the shared lock" as being unconditional, i.e. even if there is a blocking call to lock() to acquire an exclusive lock, then that means that readers (shared locks) are given priority over writers (exclusive locks). https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock#Priority_policies > On windows, no shared lock can be acquired anymore once a UniqueLock > requested a lock. That means that writers (exclusive locks) are given priority over readers (shared locks). But as far as I can tell the C++ standard does not specify or guarantee either behaviour, so both are valid. To be portable your code should not assume that shared locks get priority over exclusive locks, or vice versa.
