RwLock: support upgrades/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.

[skade]

I'm not sure what such an API would look like in a handle-based language like Rust. Currently, libstd RwLock, which our RwLock is modelled after also doesn't support this.

Also, upgrading from read to write requires that all other readers are dropped, too, so this an operation that needs to be waited for and also return another other handle. So I have a hard time figuring out a good API that is better then "acquire reader -> drop reader -> acquire writer -> drop writer -> acquire reader again`.

[d-e-s-o]

So I have a hard time figuring out a good API that is better then "acquire reader -> drop reader -> acquire writer -> drop writer -> acquire reader again`.

This sequence is not atomic.

As for the API, intuitively I'd go with:

RwLock::write(&self) -> WriteGuard
RwLock::read(&self) -> ReadGuard
WriteGuard::downgrade(self) -> ReadGuard
ReadGuard::upgrade(self) -> WriteGuard

Also, upgrading from read to write requires that all other readers are dropped, too, so this an operation that needs to be waited for and also return another other handle.

Sure, but why is that a problem? The implementation would wait until the requestor is the last reader (and block others from acquiring new read/write access) and could then be "upgraded" into a WriteGuard.

[d-e-s-o]

The folks over at futures-rs point out that parking_lot supports upgrades and downgrades.

[skade]

@devashishdxt Gah, you are right, obviously it isn't atomic ;). Sorry, I wrote the reply far too late at night.

Well, coming back to the original problem, async-std does reimplement std in a sync fashion, so an interface should be implemented in std first unless there's a very strong cause. The reason for this is mainly that we see libstd interfaces as well-vetted and well understood.

[devashishdxt]

@devashishdxt Gah, you are right, obviously it isn't atomic ;). Sorry, I wrote the reply far too late at night.

Well, coming back to the original problem, async-std does reimplement std in a sync fashion, so an interface should be implemented in std first unless there's a very strong cause. The reason for this is mainly that we see libstd interfaces as well-vetted and well understood.

I think you tagged me by mistake ;)
@d-e-s-o

[skade]

@devashishdxt Gah! Also, don't use GH in the morning :).

[d-e-s-o]

Let me bring the suggestion to std folks then.

Edit: rust-lang/rust#69240