3 ms·

There are however many PRs about people ignoring the return values of pthread_mutex_lock(), or missing an unlock on one route through a function.

dathinab 2y ago
and nothing prevents you from explicitly dropping lock guards in rust either actually it's a common pattern in complicated multi threaded code or similar to require that
- freeone3000 2y ago
  Dropping a lock guard in rust requires you to have already dropped the borrow — the shared memory under lock is only accessible through the guard, and you can’t drop an object if you have a reference to it. This is not true in C, where you can reference the shared memory after the lock is released.
  - dathinab 2y ago
    > This is not true in C, where you can reference the shared memory after the lock is released. technically yes but practically this is nearly always programmer bug to bypass a lock
    - freeone3000 2y ago
      That is the point — this is (another) example of a programmer bug that C allows that Rust does not.
- lodovic 2y ago
  The rust compiler (or the rust-analyzer) directs developers to use mutexes or other guards, even in single-threaded code when the use case wouldn't strictly require it. Where we would get undefined behavior in C, we get deadlocks in rust. This forces developers to handle these cases, but this can be quite painful to implement, especially in embedded or no_std environments.
  - dlahoda 2y ago
    may be it directs to use unsafe?
    - dathinab 2y ago
      no not at all If you port C code to rust and now need much more locks in Rust it's nearly always an indicator for either your C code not having been correct (e.g. accessing resources behind a lock without acquiring it) and/or you having badly structured code. There is basically hardly ever a need to use unsafe for such cases as long as you don't write your own fundamental data structures (e.g. specific kinds of idk. lock free concurrent data structures). Honestly the main reason I see unnecessary unsafe code usage is people trying to write C or C++ code in rust instead of writing rust in rust.
- kelnos 2y ago
  So what? If you drop the lock guard, you get a straightforward compiler error if you later try to access the data in it. You don't get a runtime bug that you have to track down like you get if you forget a pthread_mutex_unlock().
  - dathinab 2y ago
    yes that is the point you can rely on implicit drop to always make sure you never forget to unlock (as long as you don't leak the guard which is hard to do but possible) but you can also explicitly drop it to have full control over when exactly it will unlock and in neither situation you have to worry about accidentally bypassing it and in complicated code relying implicitly on a mutex or similar to still be kept it's a common pattern to do so (i.e. to explicitly drop the mutex guard even if not needed to be extra clear about for how long exactly the lock is held)

dathinab 2y ago

and nothing prevents you from explicitly dropping lock guards in rust either actually it's a common pattern in complicated multi threaded code or similar to require that

freeone3000 2y ago
Dropping a lock guard in rust requires you to have already dropped the borrow — the shared memory under lock is only accessible through the guard, and you can’t drop an object if you have a reference to it. This is not true in C, where you can reference the shared memory after the lock is released.
- dathinab 2y ago
  > This is not true in C, where you can reference the shared memory after the lock is released. technically yes but practically this is nearly always programmer bug to bypass a lock
  - freeone3000 2y ago
    That is the point — this is (another) example of a programmer bug that C allows that Rust does not.
lodovic 2y ago
The rust compiler (or the rust-analyzer) directs developers to use mutexes or other guards, even in single-threaded code when the use case wouldn't strictly require it. Where we would get undefined behavior in C, we get deadlocks in rust. This forces developers to handle these cases, but this can be quite painful to implement, especially in embedded or no_std environments.
- dlahoda 2y ago
  may be it directs to use unsafe?
  - dathinab 2y ago
    no not at all If you port C code to rust and now need much more locks in Rust it's nearly always an indicator for either your C code not having been correct (e.g. accessing resources behind a lock without acquiring it) and/or you having badly structured code. There is basically hardly ever a need to use unsafe for such cases as long as you don't write your own fundamental data structures (e.g. specific kinds of idk. lock free concurrent data structures). Honestly the main reason I see unnecessary unsafe code usage is people trying to write C or C++ code in rust instead of writing rust in rust.
kelnos 2y ago
So what? If you drop the lock guard, you get a straightforward compiler error if you later try to access the data in it. You don't get a runtime bug that you have to track down like you get if you forget a pthread_mutex_unlock().
- dathinab 2y ago
  yes that is the point you can rely on implicit drop to always make sure you never forget to unlock (as long as you don't leak the guard which is hard to do but possible) but you can also explicitly drop it to have full control over when exactly it will unlock and in neither situation you have to worry about accidentally bypassing it and in complicated code relying implicitly on a mutex or similar to still be kept it's a common pattern to do so (i.e. to explicitly drop the mutex guard even if not needed to be extra clear about for how long exactly the lock is held)