Potential to modify ordering for load in bytes.rs and bytes_mut.rs about bytes HOT 2 CLOSED

All of the codepaths you have pointed out are reachable only when the vtable is SHARED_VTABLE. However, when this is the case, the data field is immutable and never modified. Therefore, relaxed is enough. In fact, a non-atomic load would have been enough.

To see this, note that the data pointer is only changed in one location:

However, that line of code is only callable on a Bytes or BytesMut if the vtable is PROMOTABLE_EVEN_VTABLE or PROMOTABLE_ODD_VTABLE.

from bytes.

All of the codepaths you have pointed out are reachable only when the vtable is SHARED_VTABLE. However, when this is the case, the data field is immutable and never modified. Therefore, relaxed is enough. In fact, a non-atomic load would have been enough.

To see this, note that the data pointer is only changed in one location:

bytes/src/bytes.rs

Lines 1157 to 1166 in 74e6e20

	// Try compare & swapping the pointer into the `arc` field.
	// `Release` is used synchronize with other threads that
	// will load the `arc` field.
	//
	// If the `compare_exchange` fails, then the thread lost the
	// race to promote the buffer to shared. The `Acquire`
	// ordering will synchronize with the `compare_exchange`
	// that happened in the other thread and the `Shared`
	// pointed to by `actual` will be visible.
	match atom.compare_exchange(ptr as _, shared as _, Ordering::AcqRel, Ordering::Acquire) {

However, that line of code is only callable on a Bytes or BytesMut if the vtable is PROMOTABLE_EVEN_VTABLE or PROMOTABLE_ODD_VTABLE.

I understand the code now. Using Relaxed here works fine. Thank you for your response.

from bytes.