Differential RwLocks on fields?

Does the concept exist... where one can have a write-lock on a specific field of a struct, and then have a parallel write-lock on another field working? If this is impossible and UB, would it be because the alignment would change in real-time, thus throwing-off the underlying pointer's write offset/position when one thread writes to the adjacent field?

You could wrap each field in a rwlock, but other than that, not really. RwLock can't project to certain fields.

2 Likes

What do you think about a futures-based system where each write and read op is given an "id", and once the underyling "write-count" and/or "Read count" matches the id, the future op can then execute the R/W?

This would require each struct have a "current_read_id" and "current_write_id" field, and each write/read op would be a future that executes once its "ticket" (synonymous to the "ID" above) matches the current_field

That would complicate things quite a bit, but you could make an external crate for that. One hitch, there is no way to do reflection on the fields of a type, so this new RwLock will require some unsafe code to be exposed. But this seems like an interesting idea, so try it out!

1 Like

Perhaps making a #[derive ...] that takes each field of the struct and wraps it in an RwLock (like you suggested), and then mixing that with the concept I presented. This sounds like it would be a fun sunday experimental project. Thanks

2 Likes

In higher level terms you have very sophisticated locking paradigms as part of operating systems support (OSS.)

Although this is very much an application level technology there are lower level analogs.

They add complexity and kill performance usually but if you had a use case maybe.

For example, BTree persistence sounded great until I saw the benchmarks. This is probably a big performance hit.

1 Like