Sharing a struct with thread without Sync and Send

help
1

My code is using Shmem in shared_memory - Rust and as I've read in the documentation the Shmem struct does not implement Sync + Send traits.

Is it possible in any way to share this instance of struct Exporter with a thread, while the Shmem does not implement Sync + Send?

pub struct Exporter<T> {
    ParsedFile: T,
    SharedMemories: HashMap<String, Shmem>,
    MessageQueueValues: HashMap<String, Vec<u8>>,
}

The error message if that helps:

`*mut c_void` cannot be sent between threads safely
within `shared_memory::Shmem`, the trait `Send` is not implemented for `*mut c_void`, which is required by `{closure@src\main.rs:86:32: 86:39}: Send`
required for `Mutex<shared_memory::Shmem>` to implement `Sync`
required for `Arc<Mutex<shared_memory::Shmem>>` to implement `Send`
required because it appears within the type `(std::string::String, Arc<Mutex<shared_memory::Shmem>>)`
required for `hashbrown::raw::RawTable<(std::string::String, Arc<Mutex<shared_memory::Shmem>>)>` to implement `Send`
2

The API looks like you are supposed to access shared memory regions via their ID. Here's a multi-threaded example linked from the official documentation.

Supposing you already looked at these examples, what's wrong with them?

1 Like
3

In general, when you encounter a type that isn't Send, there are multiple possibilities for what the situation is:

  1. The Shmem could just be Send, or Send + Sync, but the library didn't add the required unsafe impl Send to mark it so. In that case, a PR to the library would be appropriate.
  2. The Shmem is not sound to send or share, but it could be — additional care would be needed. A less trivial modification.
  3. The Shmem would be unsound if sent. In that case, you must create it on the thread it is to be used on. One useful technique here is the “actor”: create a thread to own the Shmem, and make use of it by sending messages over a channel from other threads that need to use it.

It's impossible to know which of these 3 cases applies without studying the actual code in the shared_memory library, and the system calls involved.

3 Likes
4

The problem is that I want to have program which serves this ID dynamically to any process that will request it. This serving functionality I want to have in separate thread of my program.

While writing it, I thought I need the instance of Shmem moved to the thread, but right now, when you responded, I think I can just move os_id which is String.

5

That example looks very worrying. It is using read_volatile and unsynchronized writes to write to the same piece of memory from multiple threads, resulting in multiple data races which are UB.

1 Like
6

Yes, but that's another problem. (It even says that in the comments.) But it does demonstrate that the Shmem type itself is not to be shared but re-created based on its ID.

7

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.