So you want to be considered by T-libs?

[workingjubilee]

Before it is worth putting in the queue for review:

1. This crate must pass miri. Ideally it would also pass miri with the following flags:

• -Zmiri-strict-provenance #12
• -Zmiri-symbolic-alignment-check #13
• -Zmiri-tree-borrows #14

2. This crate must be sound against all the correctness errors we have encountered in Arc and Rc and solved:

• Overflow in Arc rust-lang/rust#108706
• {Rc,Arc}::{new_uninit_slice,from_iter} create too large references rust-lang/rust#95334
• Arc::drop has a (potentially) dangling shared ref rust-lang/rust#55005
• Insufficient synchronization in Arc::get_mut rust-lang/rust#51780
• UB inside Weak::as_ptr rust-lang/rust#80365
• arc::Weak::upgrade does not account for overflow rust-lang/rust#30031
• From<&[T]> for Rc creates underaligned reference rust-lang/rust#54908

3. In addition you must validate that it remains sound and fast even when used on "weak memory model" platforms. PowerISA (aka POWER aka PowerPC) is the weakest I know of for modern CPUs, but in a pinch, testing on AArch64 should flush out most problems, and is more important because we support aarch64-unknown-linux-gnu as a tier 1 platform. That makes its soundness in implementation of consequently higher concern, though we do take correctness seriously for tier 2 platforms, we're just humans with priorities.

4. Finally, and this is the most subjective evaluation: There has to be a reason to actually include it in std instead of just leaving it as an external crate. It's not good enough for it to simply be faster in a few cases. We often reject new API simply if it is too confusing or niche to choose when to use it.

[workingjubilee]

Prior verification efforts of the Rust standard library of interest:

• RustBelt: Securing the Foundations of the Rust Programming Language. https://plv.mpi-sws.org/rustbelt/popl18/
• RustBelt meets relaxed memory. https://doi.org/10.1145/3371102
• Tackling Real-Life Relaxed Concurrency with FSL++. https://plv.mpi-sws.org/fsl/ARC/paper.pdf
• Tree Borrows: A New Aliasing Model for Rust. https://perso.crans.org/vanille/treebor/

...uh, you most certainly do not need to read all of these or anything, you just might find them informative since they discuss correctness and incorrectness of Rust code, and especially unsafe Rust code, extensively. The last is most novel and also most unproven but at the same time is the Rust model of operational semantics being experimented with after a hell of a lot of experimentation.

[EricLBuehler]

@workingjubilee, thank you for sending me those! I will be sure to check them out.

[EricLBuehler]

Regarding point 3, I own a Raspberry Pi 4 (has the armv8a that is a superset of aarch64 -https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/), which has an aarch64 architecture. Would soundness on this machine be an adequate check?

[workingjubilee]

It would be a useful start, at least. One of the things about the RPi that makes it not quite the same as say, an M1, is that it doesn't run a very deep pipeline with hundreds of instructions in flight, so there's no huge stalls that might trash performance in the worst case scenario. But also, it's still interesting, because the RPi lacks a straightforward implementation of compare_exchange, and instead uses atomic instructions that operate like compare_exchange_weak.

[EricLBuehler]

Yes, I hope that would be sufficent as I do not have access to, for example, and M1. The only ARM devices I have are my RPis.

Like you said, hopefully those benchmarks with the RPi will provide some contrast to more powerful and complex processors.

[workingjubilee]

I have a diverse array of CPUs, including some very exotic architectures that Rust supports, and I will be happy to run some benchmarks on my machines once you've done some initial testing.

Including an M1.

[EricLBuehler]

Thank you for the offer! I would really appreciate it - perhaps after #9 is closed. Maybe you can submit the results via pull request? Again, thank you!

[EricLBuehler]

I believe that point 3 has been resolved - See this new benchmark file which includes a benchmark on an AArch63 platform. However, if you can test Trc on your systems, that would be amazing! The benchmark file contains the shell script to reproduce the results, so it should be easy to test. Thank you!

[EricLBuehler]

Point 10 is NA because I directly allocate an array of T.

[EricLBuehler]

Point 8 is also NA because of my handling of dangling Weaks.

[EricLBuehler]

Point 6 is not a problem for Trc because if the sharedref goes to 0, then we are guaranteed to be the only ones holding a reference to SharedTrcInternal.

[EricLBuehler]

Point 7 is resolved because we have an Acquire to establish the required happens-before relationship.

[EricLBuehler]

Point 9 is resolved because we already have an overflow check.

[EricLBuehler]

Regarding section/point 4 (API nicheness), I believe that Trc's usefulness comes from it's major performance gains, as can be seen in the benchmarks. However, because Trc is currently outside of the std library, CoerceUnsized, and Receiver cannot be implemented.

Regarding DispatchFromDyn, the following from here pertains:

Other than one-aligned, zero-sized fields, the definition for Self must have exactly one field and that field’s type must be the coerced type. Furthermore, Self’s field type must implement DispatchFromDyn where F is the type of T’s field type.

Because the design of Trc means that each instance of the struct has a localcount and a sharedcount, 2 fields are present in the Trc struct. Of course, this could be implemented for the SharedTrc struct that is essentially Arc.

@workingjubilee, I would appreciate your thoughts on this, particularly regarding any workarounds I can use to implement DispatchFromDyn for Trc itself.