Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside Rust's std and parking_lot mutexes – who wins?

blog.cuongle.dev

Post reply on HN
Print view View original

121–130 of 134 posts

Re: Inside Rust's std and parking_lot mutexes – who wins?

#121

Post by scottlamb »

pizlonator wrote: post #113
scottlamb wrote: post #92

Earlier quoted context omitted.

> The WebKit post explicitly talks about how you just need two bits to describe the lock state. It describes the algorithm but not how a caller of the Rust `parking_lot` crate could take advantage of this. > Not impossible. One way to do this is to just use parking_lot directly. By "just use parking_lot directly", I think you're talking about reimplementing the parking lot algorithm or using the C++ `WTF::ParkingLot`…

> It describes the algorithm but not how a caller of the Rust `parking_lot` crate could take advantage of this. Read the WebKit post. > By "just use parking_lot directly", I think you're talking about reimplementing the parking lot algorithm or using the C++ `WTF::ParkingLot` implementation? But not actually using the existing Rust crate called `parking_lot` described in the cuongle.dev article? See https://docs.rs/p…

> Read the WebKit post.

Clearly I have already.

> See https://docs.rs/parking_lot_core/latest/parking_lot_core/ ... That's my ParkingLot API.

"just use parking_lot directly" is a weird way to say "use the `parking_lot_core` crate instead of the `parking_lot` crate".

...and note that I mentioned this in my earlier comment: (slightly more realistically, you could probably use the `parking_lot_core::park` portion of the implementation and build your own equivalent of `parking_lot::RawMutex` on top of it)

I'm not trying to be disagreeable here, but really you could save a lot of trouble if you were a bit more careful in your communication.

Re: Inside Rust's std and parking_lot mutexes – who wins?

#122

Post by dap »

JoshTriplett wrote: post #114
dap wrote: post #111

Earlier quoted context omitted.

You seem to keep making the implicit assumption that because people are using `unwrap()`, they must not care about the poisoning behavior. I really don't understand where this assumption is coming from. I explicitly want to propagate panics from contexts that hold locks to contexts that take locks. The way to write that is `lock().unwrap()`. I get that some people might write `lock().unwrap()` not because they care a…

https://news.ycombinator.com/item?id=46051602 I'm suggesting that the balance of pain to benefit is not working out enough to inflict it on everyone by default. I'm not suggesting it has no value, just not enough to be worth it.

I hear that, but it feels kind of empty because I haven't seen much discussion of that cost/benefit analysis (both of poisoning itself and of the change to the default behavior, which has its own costs and benefits).

I take it as uncontroversial that an important function of Mutexes is to ensure that invariants about data are maintained when the data is modified and that very bad things can happen when a program's data invariants are violated at runtime and the program doesn't notice. Maybe folks disagree about whether a program should always panic when invariants are violated at runtime (though there's certainly plenty of precedent in Rust itself for doing this, like with array bounds checking). Probably the bigger question mark is that panicking with a Mutex held doesn't necessarily mean an invariant is violated. But it does mean that the mechanism for ensuring the invariant has itself failed. I can see different choices about what to do here. For myself, the event itself is so rare and the impact of getting an invariant wrong so high that I absolutely do want to panic -- the false positive rate is just too small to matter.

Re: Inside Rust's std and parking_lot mutexes – who wins?

#123

Post by tomhow »

questioner8216 wrote: post #119
aw1621107 wrote: post #118

Earlier quoted context omitted.

Perhaps it might help to clarify precisely what claim(s) you think are being made? From my reading, the section (and the article in general, really) is specifically focusing on mutexes, so the observations the article makes are indeed accurate in that respect (i.e., C++'s std::mutex indeed does not have automatic unlocking; you need to use an external construct for that functionality). Now, if the article were talkin…

[flagged]

Please stop registering accounts to post guidelines-breaking comments like this in Rust-related threads. Other community members are noticing. It's an abuse of HN to do this and we have to ban accounts that keep doing it.

Re: Inside Rust's std and parking_lot mutexes – who wins?

#124

Post by questioner8216 »

tomhow wrote: post #123
questioner8216 wrote: post #119

Earlier quoted context omitted.

[flagged]

Please stop registering accounts to post guidelines-breaking comments like this in Rust-related threads. Other community members are noticing. It's an abuse of HN to do this and we have to ban accounts that keep doing it.

I am not breaking any rules, instead my comments are on point and show better debate culture than other comments, including better than yours and the previous comment. Please do better. You are at fault 100%, and you are well aware of it.

Edit: Downvoting comments that you know are good, is even further against good debate practice. You are doing worse and worse, and you are well aware of it. Have some shame.

Re: Inside Rust's std and parking_lot mutexes – who wins?

#125

Post by tomhow »

questioner8216 wrote: post #124
tomhow wrote: post #123

Earlier quoted context omitted.

Please stop registering accounts to post guidelines-breaking comments like this in Rust-related threads. Other community members are noticing. It's an abuse of HN to do this and we have to ban accounts that keep doing it.

I am not breaking any rules, instead my comments are on point and show better debate culture than other comments, including better than yours and the previous comment. Please do better. You are at fault 100%, and you are well aware of it. Edit: Downvoting comments that you know are good, is even further against good debate practice. You are doing worse and worse, and you are well aware of it. Have some shame.

The guidelines apply to everyone. If you continue breaking them with this account or other old or new accounts, they’ll be banned. No further warnings.

Re: Inside Rust's std and parking_lot mutexes – who wins?

#126

Post by questioner8216 »

tomhow wrote: post #125
questioner8216 wrote: post #124

Earlier quoted context omitted.

I am not breaking any rules, instead my comments are on point and show better debate culture than other comments, including better than yours and the previous comment. Please do better. You are at fault 100%, and you are well aware of it. Edit: Downvoting comments that you know are good, is even further against good debate practice. You are doing worse and worse, and you are well aware of it. Have some shame.

The guidelines apply to everyone. If you continue breaking them with this account or other old or new accounts, they’ll be banned. No further warnings.

[flagged]

Re: Inside Rust's std and parking_lot mutexes – who wins?

#127

Post by mrlonglong »

mrlonglong wrote: post #50

The C++ example given in the article is not correct. In C++ a mutex can wrap the object being protected.

    #include 
    #include 
    #include 

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

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

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

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

   void threadFunction(SharedResource& resource) {
       resource.setValue(42);
      std::cout

Re: Inside Rust's std and parking_lot mutexes – who wins?

#128

Post by mrlonglong »

mrlonglong wrote: post #127
mrlonglong wrote: post #50

The C++ example given in the article is not correct. In C++ a mutex can wrap the object being protected.

#include #include #include class SharedResource { private: int value; std::mutex mtx; public: SharedResource() : value(0) {} void setValue(int newValue) { std::lock_guard guard(mtx); value = newValue; } int getValue() { std::lock_guard guard(mtx); return value; } }; void threadFunction(SharedResource& resource) { resource.setValue(42); std::cout

This prevents access to the variable being protected by the mutex.

Re: Inside Rust's std and parking_lot mutexes – who wins?

#129

Post by Rusky »

JoshTriplett wrote: post #102
questioner8216 wrote: post #94

Earlier quoted context omitted.

I am not sure that I understand what scoped panic hooks would or might look like. Are they maybe similar to something like try-catch-finally in Java? Would the language force the programmer to include them in certain cases somehow? If a request handler for example has at some point in time 7 nested calls, in call no. 2 and call no. 6 have resources and partial computation that needs clean-up somehow and somewhere, an…

For the simple case, suppose that you're writing a TUI application that takes over the terminal. When it exits, even by panic, you want to clean up the terminal state so the user doesn't have to blindly type "reset". Today, people sometimes do that by using `panic = "unwind"`, and writing a `catch_unwind` around their program, and using that to essentially implement a "finally" block. Or, they do it by having an RAII…

> Suppose, instead, we had a mechanism that allowed registering arbitrary panic hooks, and unregistering them when no longer needed, in any order. Then, we could do RAII-style resource handling: you could have a `CursesTerminal` type, which is responsible for cleaning up the terminal, and it cleans up the terminal on `Drop` and on panic. To do the latter, it would register a panic hook, and deregister that hook on `Drop`.

This doesn't get rid of unwinding at all- it's an inefficient reimplementation of it. There's a reason language implementations have switched away from having the main execution path register and unregister destructors and finally blocks, to storing them in a side table and recovering them at the time of the throw.

Re: Inside Rust's std and parking_lot mutexes – who wins?

#130

Post by strbean »

scottlamb wrote: post #40
strbean wrote: post #7

Earlier quoted context omitted.

Seems like the simple solution to this problem would be to have both, no? A simple native lock in the standard library along with a nicer implementation (also in the standard library) that depends on the simple lock?

The simplest solution is for `std::mutex` to provide a simple, efficient mutex which is a good choice for almost any program. And it does. Niche programs can pull in a crate. I doubt `parking_lot` would have been broadly used—maybe wouldn't even have been written—if `std` had this implementation from the start. What specifically in this comparison made you think that `parking_lot` is broadly needed? They had to work…

With zero prior knowledge of the context, the impression I got from the parent comment was that `parking_lot` had features that made it desirable enough that there was a decent amount of discussion about replacing the standard lib locks with it. I didn't catch that the previous standard lib option was terrible and has since been replaced with something better.
Post reply on HN