search

MystenLabs / sui

Sui, a next-generation smart contract platform with high throughput, low latency, and an asset-oriented programming model powered by the Move programming language
https://sui.io
Apache License 2.0
6.14k stars 11.17k forks source link

RwLock for &T when T is a SWO #8689

Open nmboavida opened 1 year ago

nmboavida commented 1 year ago

ObjectArg::ImmOrOwnedObject(ObjectRef) only has the object ID and does not distinguish whether a SWO is borrowed as a immutable or mutable reference. By bundling immutable objects and SWO in a single enum type with an ObjectRef we are not passing the info about whether we're dealing with T, &mut T or &T.

This means that when authority::handle_transaction_impl() gets called and when we get owned_objects via input_objects.filter_owned_objects() there is no way to distinguish if those owned objects are T, &mut T or &T. These owned_objects then get passed to set_transaction_lock() as mutable_input_objects even though some might be immutable, and therefore we are always acquiring Mutex, even though &T only needs RwLock.

In effect this means we can't parallelize transactions that use immutable SWO references.

It would be great to know if is there any chance this gets changed any time soon, or am I missing something?

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

andll commented 1 year ago

Hi @nmboavida, we do have RWLocks for shared object references now(via mutable flag on shared arg), but you are right we do not support this for owned objects and all owned object references are treated as mutable.

We are considering introducing owned object RWLocks as well in the future releases. If you can share the use case where you could leverage owned object RWLocks this perhaps can help us to decide on the priority