The reasoning is that there is no benefit to holding a write guard here, as in addition to keeping the object frozen, it prohibits any potential readers from accessing it during finalization; a read guard in its place still won't allow the process to be modified for the entire duration of the atomic batch, but it will allow other potential concurrent readers in the meantime. Unless the state of the process (or any of its contents) during finalization should not be visible to anyone else or should be considered outright invalid until it concludes, a read guard is the more performant choice.
I haven't been able to measure the impact of this change locally, but I'm confident it would make a difference in networks involving more traffic.
Moved from https://github.com/ProvableHQ/snarkVM/pull/19.
The reasoning is that there is no benefit to holding a write guard here, as in addition to keeping the object frozen, it prohibits any potential readers from accessing it during finalization; a read guard in its place still won't allow the
processto be modified for the entire duration of the atomic batch, but it will allow other potential concurrent readers in the meantime. Unless the state of theprocess(or any of its contents) during finalization should not be visible to anyone else or should be considered outright invalid until it concludes, a read guard is the more performant choice.I haven't been able to measure the impact of this change locally, but I'm confident it would make a difference in networks involving more traffic.