0

I've just read the section of The Rust Programming Language about sharing the data between threads. The task is simple: to share a counter between multiple threads and increment it from these threads.

My C++ solution:

  1. create a simple variable on stack
  2. create mutex
  3. share both between threads
  4. do the job

The Rust solution, as suggested by the book:

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

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..10 {
        let counter = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            let mut num = counter.lock().unwrap();

            *num += 1;
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Result: {}", *counter.lock().unwrap());
}

In C++ terms, it means creating a std::shared_ptr for storing the counter. Is it really the best what can be done here to solve the task? It looks like significant overhead in comparison with the C++ solution.

trent
  • 25,033
  • 7
  • 51
  • 90
StrausMG
  • 335
  • 1
  • 10
  • 3
    I believe your question is already answered by the answers in [How can I pass a reference to a stack variable to a thread?](https://stackoverflow.com/q/32750829/155423). If you disagree, please [edit] your question to explain the differences. If not, we can mark this as already answered. – Shepmaster Apr 22 '18 at 17:07
  • @Shepmaster oh, thanks a lot, that question is totally relevant (unfortunately, the answer for it says my goal cannot be accomplished in a concise way; I will create an issue in the Rust repository, because to me the situation looks ridiculous). – StrausMG Apr 22 '18 at 19:26
  • What do you feel would be more concise while keeping memory safety? Remember that *nothing forces you to use Rust*. If you prefer the conciseness of C++ with the corresponding potential for memory unsafety, it's totally cool to stay with what you know. Also, idiomatic Rust makes heavy use of crates, so the fact that a crate is needed to accomplish this goal is unlikely to sway any opinions. Remember that even random number generation isn't part of the standard library; we *like* to use crates. – Shepmaster Apr 22 '18 at 19:58
  • I'm also biased, as I don't think [the solution is particularly verbose](https://play.rust-lang.org/?gist=2660c7e66b1c33f844c9605c2f1c25ab&version=stable). – Shepmaster Apr 22 '18 at 20:02
  • Well, if I'm not mistaken, both of crates given in that answer are not actively maintained. – StrausMG Apr 22 '18 at 20:42
  • (a) Why does something that does one thing well *need* to be maintained? The crates may just be "complete". (b) [crossbeam had a commit 2 months ago](https://github.com/crossbeam-rs/crossbeam) and I know is undergoing a refactoring. It's also mostly composed of [smaller crates](https://github.com/crossbeam-rs) that are recently updated. [scoped-threadpool](https://github.com/Kimundi/scoped-threadpool-rs) had a commit 7 months ago but no reported issues. – Shepmaster Apr 22 '18 at 20:54

0 Answers0