Tracking Issue for {Mutex, RwLock, ReentrantLock}::data_ptr

[jplatte]

Feature gate: #![feature(mutex_data_ptr)], #![feature(rwlock_data_ptr)], #![feature(reentrant_lock_data_ptr)]

This is a tracking issue for allowing unguarded access to the inner value of a Mutex or RwLock. Previous discussion here: rust-lang/libs-team#531

Public API

// std::sync

impl<T: ?Sized> Mutex<T> {
    pub fn data_ptr(&self) -> *mut T;
}

impl<T: ?Sized> RwLock<T> {
    pub fn data_ptr(&self) -> *mut T;
}

// This type is unstable under feature `reentrant_lock`
impl<T: ?Sized> ReentrantLock<T>  {
    pub fn data_ptr(&self) -> *mut T;
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Implementation: Add data_ptr method to Mutex and RwLock #140369
• Add examples to documentation
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Return a LockResult or not?
• Return *mut T like existing APIs (Cell::as_ptr / MaybeUninit::as[_mut]_ptr / Vec::as_ptr / ...) or be more precise and return NonNull<T>?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[peter-lyons-kehl]

@jplatte, @tgross35 or anyone with access: Please update the list of feature gates to also include #![feature(reentrant_lock_data_ptr)].
Thanks in advance.

[peter-lyons-kehl]

This tracking issue and the previous discussion (so far) haven't discussed making (or not making) data_ptr a const fn. It seems to be very easy (pull request).

A use case: static array data held in a Mutex (never modified after initialized) AND further static pointers/references/slices to such an array (with LLVM de-duplication "disabled" by passing the Mutex through core::hint::black_box).

An example (which doesn't compile with the current implementation; it should compile with that pull request unless there's a typo in this example - I'm not re-configuring my toolchain at the moment):

#![cfg_attr(feature = "mx", feature(mutex_data_ptr))]
type U8Array = [u8; 3];
pub static MX: std::sync::Mutex<U8Array> = core::hint::black_box(std::sync::Mutex::new([b'A', b'B', b'C']));

// data_ptr() needs to be `const fn`:
pub static STR_FULL: &'static str = unsafe { core::str::from_utf8_unchecked(
                                               (&*MX.data_ptr() as &U8Array).as_slice()
                                             ) };

Current implementation doesn't allow such pointers/references/slices to be static. A workaround is to wrap the cast slice arithmetic (if any) in functions. The casts are zero-cost and slice arithmetic may be inlined/optimized away, but it's still ugly:

#[inline(always)]
fn str_full() -> &'static str {
    let bytes = unsafe { &*MX.data_ptr() as &U8Array };
    let bytes_slice = &bytes[..];
    unsafe { core::str::from_utf8_unchecked(bytes_slice) }
}

This use case is becoming important given the planned 2027-or-so discontinuation of/hard error for static mut. There is no other zero-cost portable or foreign-static-free alternative (other than LazyLock, which is not zero cost).

However, even worse than "ugliness", data_ptr by being "non-const" prevents its results to be used in static expressions (possibly returning an empty tuple ()), whose only purpose is compile-time checks/validations (compile time "tests"). Yes, controversial or personal preference, and limited by using const functions/expressions only. But, helpful, especially in IDE's with rust-analyzer: Compile-time failures of such expressions warn the developer early, without a need to run any tests = faster iterations. (Again, an example that should compile with that pull request but I didn't check. I do have similar use cases which involve pointer/slice arithmetic: hash-injector -> signal.rs):

static STR_FULL_ADDRESS_CHECK () = {
    if !core::ptr::eq(MX.data_ptr() as *const u8, STR_FULL.as_ptr()) {
       panic!("...");
};
static STR_FULL_CONTENT_CHECK () = {
    if STR_FULL!= core::hint::black_box("abc") {
       panic!("...");
    }
};

As-is implementation is const fn-compatible: data_ptr for all three types can be changed to const fn. Are there any platform/architecture-specific, design or future-proofing reasons against this?

[tgross35]

I don't think there is any reason not to make these const.

This use case is becoming important given the planned 2027-or-so discontinuation of/hard error for static mut. There is no other zero-cost portable or foreign-static-free alternative (other than LazyLock, which is not zero cost).

I believe the consensus here has been amended and static mut is no longer going away, see #53639.

[Amanieu]

I also agree. Since this is still an unstable API, you can just send a PR to change it to const fn.