RwLock: support upgrades and downgrades

[d-e-s-o]

I think it would be great (certainly useful for me) if RwLock were to support read-write upgrades and write-read downgrades. Currently I don't see a way to accomplish the same and I always have to get write access over the entire operation.

parking_lot currently supports both cases (here & here). I also understand that there exists a proposal to use parking_lot as the lock implementation backend.

Once (if) that lands, it should merely be a matter of extending the std APIs to provide such support.

[sfackler]

Even though we want to move the internals to parking_lot, that's an implementation detail. I don't think we'd want to expand the API beyond what pthreads provides.

[d-e-s-o]

Why?

[sfackler]

It would prohibit us from backing synchronization primitives with pthreads.

[d-e-s-o]

Correct me if I am wrong (I am not familiar with the implementation), but we could always implement our own set of synchronization primitives and, in fact, that seems to be what the switch to parking lot seems to be about.

Part of the reason for that switch seems to lie in the subtleties and "weird" behaviors of the OS specific APIs. I'd go so far to fudge pthreads into this category and just ignore it to the degree possible instead of lifting it to some form of gold standard (that's not exactly what you are saying, but to me it almost amounts to the same thing, because everything extending the limited API surface they have is ignored).

I'd argue that it is reasonable for a reader-writer lock in the standard library to provide support for such functionality. It's not that an upgrade/downgrade can be emulated easily (at least I am not aware of a way). As such, it can be seen essential (if only in some and not all cases) to write the most performant code -- which I understand is what Rust aims to enable.

[sfackler]

pthreads is not a gold standard, it is a least common denominator. The standard library does not intend to provide arbitrarily obscure functionality.

I disagree that these operations are "essential" - C# is the only language that I'm aware of that offers them as part of its standard library.

[Dylan-DPC]

Closing this as it is not intended and can be considered implementation details based on the discussion above

[oxalica]

I don't think we'd want to expand the API beyond what pthreads provides.

Since #93740, we are no longer limited by functionalities provided by pthreads. Could we revisit this feature request?

[ChrisDenton]

Nowadays your best bet would to open an API Change Proposal (ACP) that sketches the API you'd like and explains the motivation for it.