News for hackers. Stuff that matters.
Re:Common Rust Lifetime Misconceptions by ForkMeOnTinder on Monday December 04, 2023 @09:12PM (#38526149)
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.
Re:Common Rust Lifetime Misconceptions by gnulinux on Monday December 04, 2023 @11:56PM (#38527275)
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.
Re:Common Rust Lifetime Misconceptions by afdbcreid on Tuesday December 05, 2023 @12:06AM (#38527324)
`RefCell` does have one big advantage, though: it'll panic instead of deadlock for reentrant borrow.
Re:Common Rust Lifetime Misconceptions by spacechild1 on Tuesday December 05, 2023 @01:50AM (#38527830)
> 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.

Re:Common Rust Lifetime Misconceptions by gpderetta on Tuesday December 05, 2023 @02:53AM (#38528148)
An atomic read-modify-write. Atomic non-seq-cst load/stores can be cheap.

/Overly pedantic

Re:Common Rust Lifetime Misconceptions by spacechild1 on Tuesday December 05, 2023 @05:34AM (#38529174)
> 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.

Re:Common Rust Lifetime Misconceptions by gpderetta on Tuesday December 05, 2023 @07:18AM (#38529907)
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.

Re:Common Rust Lifetime Misconceptions by jlffwoymasdf on Monday December 04, 2023 @09:28PM (#38526288)
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.

Re:Common Rust Lifetime Misconceptions by ben-schaaf on Tuesday December 05, 2023 @03:30AM (#38528298)
Doesn't tokio have a single-threaded runtime where that's not needed?
Re:Common Rust Lifetime Misconceptions by zackangelo on Tuesday December 05, 2023 @08:16AM (#38530295)
Yes but Send + Sync is required everywhere regardless.
Re:Common Rust Lifetime Misconceptions by vgatherps on Tuesday December 05, 2023 @10:36AM (#38532207)
This is not true, you can run non-send futures using Tokio: https://docs.rs/tokio/latest/tokio/task/struct.LocalSet.html
Re:Common Rust Lifetime Misconceptions by packetlost on Monday December 04, 2023 @09:37PM (#38526372)
Eh, I don't think the overhead of an uncontested lock acquire is all that much.