Inside Rust's std and parking_lot mutexes – who wins? (blog.cuongle.dev)

Whereas parking_lot has a ton of problematic scenarios, where after the spinlock times out, and it yields the thread to the OS, which has no idea to wake up the thread after the resource is unblocked.

It could be even argued that preventing starvation is outside the design scope of the Mutex as a construct, as it only guarantees mutual exclusion and that the highest priority waiting thread should get access to it.

Is it safe to ignore poisoned mutexes if and only if the relevant pieces of code are unwind-safe, similar to exception safety in C++? As in, if a panic happens, the relevant pieces of code handles the unwinding safely, thus data is not corrupted, and thus ignoring the poison is fine?

There's a tension between making DoS hard and avoiding RCE vulnerabilities, since the way to avoid an unplanned/bad code state becoming an RCE vulnerability is to crash as quickly and thoroughly as possible when you get into that state.

I mean, think about the actual use cases here. On of my threads just panicked. Does it make sense to continue running the application? And if you answer yes, this is an error condition that can occur, then it shouldn't panick to begin with and instead handle errors gracefully, leaving the mutex unpoisoned.

In 99% of the cases where one thread has panic'd while holding a lock, you want to panic the thread that attempts to grab the lock. The contents of anything inside the lock is very much undefined and continuing will lead to unpredictable results. So most of the time you just want:

    let guard = mutex.lock().expect("poisoned");

    let guard = mutex.lock().unwrap_or_else(|poison| poison.into_inner());

This might be the case for long running server processes where you have n:m threading with long running threads and want to keep processing other requests even if one request fails. Although in that case you probably want (or your framework provides) some kind of robustness with `catch_unwind` that will log the errors, respond with HTTP 500 or whatever and then resume. Because that's needed to catch panics from non-mutex related code.

One reason not to provide the owning mutex in C++ is that it isn't able to deliver similar guarantees to Rust because its type system isn't strong enough. Rust won't let you accidentally keep a reference to the protected object after unlocking, C++ will for example.

In C++, a class like std::lock_guard also provides "Automatic unlock". AFAICT, the article argues that only Rust's API provides that.

    {
        const std::lock_guard<std::mutex> lock(mtx);
        account.balance -= amount;
        account.transaction_count++;
    } // Automatically unlocked.

    #include <iostream>
    #include <mutex>
    #include <thread>

    class SharedResource {
    private:
        int value;
        std::mutex mtx;

    public:
        SharedResource() : value(0) {}

        void setValue(int newValue) {
            std::lock_guard<std::mutex> guard(mtx);
            value = newValue;
        }

        int getValue() {
             std::lock_guard<std::mutex> guard(mtx);
             return value;
       }
   };

   void threadFunction(SharedResource& resource) {
       resource.setValue(42);
      std::cout << "Value: " << resource.getValue() <<   std::endl;
    }

    int main() {
        SharedResource resource;
        std::thread t1(threadFunction, std::ref(resource));
        std::thread t2(threadFunction, std::ref(resource));

        t1.join();
        t2.join();

       return 0;
   }