3 ms·
This is also a problem with Rust conversations and tutorials online: There's a lot of talk about what not to do or what you can't do in Rust, but it's rarely fo
by PragmaticPulp 5y ago
This is also a problem with Rust conversations and tutorials online: There's a lot of talk about what not to do or what you can't do in Rust, but it's rarely followed up with an explanation of what users should do.
Mutexes aren't an entirely foreign concept to many programmers. Obviously if someone can architect their system in a way that doesn't require Arc<Mutex<_>> then go for it, but we need to be careful about giving blanket advice without alternatives.
- rmdashrfstar 5y agoIndeed, this blanket advice does not apply in situations where shared resources that require mutable access need to be synchronized. If my async HTTP router is serving two requests that are using the same database client to persist changes, that needs to be synchronized. How does one do this without a mutex?
- ibraheemdev 5y agoUse a database pool, although some pool implementations may use mutexes internally.
- barsonme 5y agoBy acquiring and releasing resources. I’m not intimately familiar with Rust, so I’ll use Go as an example. Create a one-buffered channel: `make(chan T, 1)`. To acquire, receive from the channel. If the object is in use, the receive will block (goroutine put to sleep) until it’s available. To release, send the acquired object to the channel. On a language level, no mutexes.
- waffletower 5y agoThere are STM (Software Transactional Memory) implementations in Rust.
- lmm 5y agoThe lifetime/borrow-checking is the mutex. If you've got a database client that must only be used by one caller at a time, make a function that takes the client as &mut.