https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102962
Daniel <taf.undying at gmx dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |taf.undying at gmx dot de
--- Comment #5 from Daniel <taf.undying at gmx dot de> ---
(In reply to Jonathan Wakely from comment #4)
> FWIW, POSIX says this for its equivalent of lock_shared:
>
> If the Thread Execution Scheduling option is not supported, it is
> implementation-defined whether the calling thread acquires the lock when a
> writer does not hold the lock and there are writers blocked on the lock.
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/
> pthread_rwlock_rdlock.html
>
> The C++ proposals for shared mutex said:
>
> An implementation is strongly encouraged to block other threads requesting
> shared ownership while this thread is blocked waiting for exclusive
> ownership, lest the blocked thread be starved by readers.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3568.html
>
> However, that was for the upgrade lock functionality, which never made it
> into the standard. The final wording for shared_mutex (and
> shared_timed_mutex) do not even have that encouragement.
Even with an implementation defined scheduling order, wouldn't most people
expect that it prevents thread starvation? That also seems to be suggested by
N3568.
And this here is a "real-life" of how writer starvation can happen with the
current code.
So while I see your point that it is technically not a bug, wouldn't it still
make sense to change it?
