`RefCell` cannot be shared between threads safely?

Question

This is a continuation of How to re-use a value from the outer scope inside a closure in Rust? , opened new Q for better presentation.

// main.rs

    // The value will be modified eventually inside `main` 
    // and a http request should respond with whatever "current" value it holds.
    let mut test_for_closure :Arc<RefCell<String>> = Arc::new(RefCell::from("Foo".to_string()));

// ...

    // Handler for HTTP requests
    // From https://docs.rs/hyper/0.14.8/hyper/service/fn.service_fn.html
    let make_svc = make_service_fn(|_conn| async {
        Ok::<_, Infallible>(service_fn(|req: Request<Body>| async move {
            if req.version() == Version::HTTP_11 {
                let foo:String = *test_for_closure.borrow();
                Ok(Response::new(Body::from(foo.as_str())))
            } else {
                Err("not HTTP/1.1, abort connection")
            }
        }))
    });

Unfortunately, I get RefCell<std::string::String> cannot be shared between threads safely:

enter image description here

C. Lang · Accepted Answer

RefCell only works on single threads. You will need to use Mutex which is similar but works on multiple threads. You can read more about Mutex here: https://doc.rust-lang.org/std/sync/struct.Mutex.html.

Here is an example of moving an Arc<Mutex<>> into a closure:

use std::sync::{Arc, Mutex};

fn main() {
    let mut test: Arc<Mutex<String>> = Arc::new(Mutex::from("Foo".to_string()));

    let mut test_for_closure = Arc::clone(&test);
    let closure = || async move {
        // lock it so it cant be used in other threads
        let foo = test_for_closure.lock().unwrap();
        println!("{}", foo);
    };
}

Svetlin Zarev · Answer

The first error in your error message is that Sync is not implemented for RefCell<String>. This is by design, as stated by Sync's rustdoc:

Types that are not Sync are those that have “interior mutability” in a non-thread-safe form, such as Cell and RefCell. These types allow for mutation of their contents even through an immutable, shared reference. For example the set method on Cell takes &self, so it requires only a shared reference &Cell. The method performs no synchronization, thus Cell cannot be Sync.

Thus it's not safe to share RefCells between threads, because you can cause a data race through a regular, shared reference.

But what if you wrap it in Arc ? Well, the rustdoc is quite clear again:

Arc will implement Send and Sync as long as the T implements Send and Sync. Why can’t you put a non-thread-safe type T in an Arc to make it thread-safe? This may be a bit counter-intuitive at first: after all, isn’t the point of Arc thread safety? The key is this: Arc makes it thread safe to have multiple ownership of the same data, but it doesn’t add thread safety to its data. Consider Arc<RefCell>. RefCell isn’t Sync, and if Arc was always Send, Arc<RefCell> would be as well. But then we’d have a problem: RefCell is not thread safe; it keeps track of the borrowing count using non-atomic operations.

In the end, this means that you may need to pair Arc with some sort of std::sync type, usually Mutex.

Arc<T> will not be Sync unless T is Sync because of the same reason. Given that, probably you should use std/tokio Mutex instead of RefCell

`RefCell<std::string::String>` cannot be shared between threads safely?

Tags:

rust

hyper

rollingBalls

2 Answers

C. Lang

Svetlin Zarev

Recent Activity

Donate For Us