These are chat archives for rust-lang/rust

22nd
Mar 2018
Daniel Bischof
@dbischof90
Mar 22 2018 07:11
How does https://doc.rust-lang.org/src/alloc/arc.rs.html#858-871 work in a multi-treaded environment? If I have two threads accessing the arc in parallel, will get_mut return None one time?
Andrey Lesnikov
@ozkriff
Mar 22 2018 07:19

Returns a mutable reference to the inner value, if there are no other Arc or Weak pointers to the same value.
Returns None otherwise, because it is not safe to mutate a shared value.

Yep, that's the idea

Daniel Bischof
@dbischof90
Mar 22 2018 07:19
Eh, damn. Okay, thanks
Michal 'vorner' Vaner
@vorner
Mar 22 2018 07:25
I think it'll return None both times.
Daniel Bischof
@dbischof90
Mar 22 2018 08:52
:(
Michal 'vorner' Vaner
@vorner
Mar 22 2018 08:52
If you want multiple threads „fighting“ over it, you may want Arc<Mutex<T>>.
Daniel Bischof
@dbischof90
Mar 22 2018 09:20
I'm fiddling around with a Hashmap carrying async senders. While I think that there will not be a latency problem
*.... I was at the situation that I need mutable references to the senders, so that possibly two futures (getting something from a tcpstream, do some stuff with it and stuff it into the right dedicated thread through bespoken sender) could send something through two different senders in parallel - but with mutex I'm effectively single-threaded again, since only one thread can get a sender at the same time.
Michal 'vorner' Vaner
@vorner
Mar 22 2018 09:26
Are you sure the send itself will take long to block others from sending? Also, if I read it right, you have multiple senders, so is it likely they'll collide on the same one?
Daniel Bischof
@dbischof90
Mar 22 2018 09:44
I don't think so, I'm overcomplicating that big time😄
Just playing around with "hm, let's try that too."
Denis Lisov
@tanriol
Mar 22 2018 11:20
@dbischof90 Do you modify the hashmap often?
Daniel Bischof
@dbischof90
Mar 22 2018 12:15
No, that's even completely static.
Why?
I only need mutable references to the mpsc::Sender in the HashMap for try_send, which is of course absolutely unfortunate.
I was already thinking about putting a crossbeam-scope around the executor but.. oh well. If I stay single-threaded here I don't have to carry the weight of Arc and Rwlock/Mutex with me.
Daniel Bischof
@dbischof90
Mar 22 2018 12:20
Sure, with crossbeam neither, as I can then just pass the reference but again, it doesn't feel like that will be really beneficial.
But if you have an idea, just tell me @tanriol ;) After all, that's all for playing around with the crates and seeing what's possible and what's not.
Denis Lisov
@tanriol
Mar 22 2018 12:22
Well, a heavy-weight but low-contention option is a Arc<HashMap<Mutex<Sender>>>
Daniel Bischof
@dbischof90
Mar 22 2018 12:23
I had thought of something like that actually. But it somehow felt too constructed and, as you correctly said, heavy-weight.
But good thought :)
Thanks again by the way for your continuous help with understanding the futures and tokio crates. Message passing is still a little rough but I think I understand now how it works. :)
Denis Lisov
@tanriol
Mar 22 2018 12:30
Ok, then how about a thread-local HashMap<_, Sender> which is cloned on first use?
Daniel Bischof
@dbischof90
Mar 22 2018 12:33
Does that work in a tokio-threadpool? I thought every new thread polls the next executable future from the queue. I would have to instantiate the pool manually, clone the HashMap, launch current_thread reactors on each, take handles and run those on a common executor, right?
Hm. I don't think it's worth it but it would be an interesting exercise.-
Michal 'vorner' Vaner
@vorner
Mar 22 2018 12:34
I think you can do something like lazy initialization and clone on the first use of it, not when the thread pool starts.
Daniel Bischof
@dbischof90
Mar 22 2018 12:38
Ah, that would take away the manual thread-work. How do I clone on first use? Wrap it in a structure with an Arc<HashMap> and a call-counter and do a deep-copy of that into the struct once called for the first time?
... or is there a much more elegant macro for that. ;)
Denis Lisov
@tanriol
Mar 22 2018 12:39
Michal 'vorner' Vaner
@vorner
Mar 22 2018 12:39
(there's an example at the index page)
Daniel Bischof
@dbischof90
Mar 22 2018 12:41
Oh.... I was looking at get_mut just yesterday.
Reason I wasn't too sure about this is that I am not sure whether that weak pointer is not dropped once the future finishes
Because then I'd poll the next one, the Arc is not local for that necessary and then I would essentially clone everytime.
(That's by the way why using .forward()is difficult here - until that combinator I don't know where I have to send to. So I wanted to do this via for_each.)
Ingvar Stepanyan
@RReverser
Mar 22 2018 13:54
FWIW you can avoid Arc altogether if using scoped threads (for example, via rayon)
Then it's just Mutex/RwLock