5 ms·

Good advice, though I'd recommend Rc<RefCell<T>> instead of Arc<Mutex<T>> if you're not sharing the data between threads, to avoid synchronization overhead. I u

Good advice, though I'd recommend Rc<RefCell<T>> instead of Arc<Mutex<T>> if you're not sharing the data between threads, to avoid synchronization overhead. I use Arc pretty rarely.

jlffwoymasdf 3y ago
tokio is so wide spread now such that Arc<Mutex<T>> is coincidentally the right choice. I'm not saying that's a good thing.
- ben-schaaf 3y ago
  Doesn't tokio have a single-threaded runtime where that's not needed?
  - zackangelo 3y ago
    Yes but Send + Sync is required everywhere regardless.
    - vgatherps 3y ago
      This is not true, you can run non-send futures using Tokio: https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html
packetlost 3y ago
Eh, I don't think the overhead of an uncontested lock acquire is all that much.
gnulinux 3y ago
The overhead of an uncontested lock is not much more than a memory operation but it allows you to be able to use the same code in threaded context in tokio async which is a huge benefit. Unless you need the optimization (i.e. you profiled and determined that Arc in a hot loop is slowing you down) I think it's fine to use Arc in general.
- afdbcreid 3y ago
  `RefCell` does have one big advantage, though: it'll panic instead of deadlock for reentrant borrow.
- spacechild1 3y ago
  > The overhead of an uncontested lock is not much more than a memory operation An atomic memory operation! These can be orders of magnitude slower than regular memory operations.
  - gpderetta 3y ago
    An atomic read-modify-write. Atomic non-seq-cst load/stores can be cheap. /Overly pedantic
    - spacechild1 3y ago
      > An atomic read-modify-write. No, this also applies to (non-relaxed) atomic loads and stores, depending on the platform. > Atomic non-seq-cst load/stores can be cheap. Relaxed atomic loads and stores are always cheap, but anything above requires additional memory order instructions on many platforms, most notably on ARM. Here we are talking specifically about mutexes, which follow acquire release semantics. To be clear: locking an uncontented mutex is indeed much, much cheaper than an actual call into the kernel, but it is not free either.
      - gpderetta 3y ago
        Ok, technically we both used the weasel word 'can' so we are both right. But even on ARM, these days store releases and load acquires, while not as free as on x86 are very cheap. To make my statement more precise, typically what is still expensive pretty much everywhere is anything with #StoreLoad barrier semantics, which is what you need to acquire a mutex.

Good advice, though I'd recommend Rc<RefCell<T>> instead of Arc<Mutex<T>> if you're not sharing the data between threads, to avoid synchronization overhead. I use Arc pretty rarely.

jlffwoymasdf 3y ago

tokio is so wide spread now such that Arc<Mutex<T>> is coincidentally the right choice. I'm not saying that's a good thing.

ben-schaaf 3y ago
Doesn't tokio have a single-threaded runtime where that's not needed?
- zackangelo 3y ago
  Yes but Send + Sync is required everywhere regardless.
  - vgatherps 3y ago
    This is not true, you can run non-send futures using Tokio: https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html

packetlost 3y ago

Eh, I don't think the overhead of an uncontested lock acquire is all that much.

gnulinux 3y ago

The overhead of an uncontested lock is not much more than a memory operation but it allows you to be able to use the same code in threaded context in tokio async which is a huge benefit. Unless you need the optimization (i.e. you profiled and determined that Arc in a hot loop is slowing you down) I think it's fine to use Arc in general.

afdbcreid 3y ago
`RefCell` does have one big advantage, though: it'll panic instead of deadlock for reentrant borrow.
spacechild1 3y ago
> The overhead of an uncontested lock is not much more than a memory operation An atomic memory operation! These can be orders of magnitude slower than regular memory operations.
- gpderetta 3y ago
  An atomic read-modify-write. Atomic non-seq-cst load/stores can be cheap. /Overly pedantic
  - spacechild1 3y ago
    > An atomic read-modify-write. No, this also applies to (non-relaxed) atomic loads and stores, depending on the platform. > Atomic non-seq-cst load/stores can be cheap. Relaxed atomic loads and stores are always cheap, but anything above requires additional memory order instructions on many platforms, most notably on ARM. Here we are talking specifically about mutexes, which follow acquire release semantics. To be clear: locking an uncontented mutex is indeed much, much cheaper than an actual call into the kernel, but it is not free either.
    - gpderetta 3y ago
      Ok, technically we both used the weasel word 'can' so we are both right. But even on ARM, these days store releases and load acquires, while not as free as on x86 are very cheap. To make my statement more precise, typically what is still expensive pretty much everywhere is anything with #StoreLoad barrier semantics, which is what you need to acquire a mutex.