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

131–134 of 134 posts

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

#131

Post by JoshTriplett »

Rusky wrote: post #129
JoshTriplett wrote: post #102

Earlier quoted context omitted.

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 `D…

The difference is that unwinding unwinds code that isn't necessarily prepared for it, rather than only code that explicitly wants it.

And I would expect to turn it into an efficient solution, in part by doing the "store in a side table" approach for hook registration.

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

#132

Post by Rusky »

JoshTriplett wrote: post #131
Rusky wrote: post #129

Earlier quoted context omitted.

> 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 `D…

The difference is that unwinding unwinds code that isn't necessarily prepared for it, rather than only code that explicitly wants it. And I would expect to turn it into an efficient solution, in part by doing the "store in a side table" approach for hook registration.

Giving special treatment to code that "explicitly wants" to handle unwinding means two things:

* You have to know when an API can unwind, and you have to make it an error to unwind when the caller isn't expecting it. If this is done statically, you are getting into effect annotation territory. If this is done dynamically, are essentially just injecting drop bombs into code that doesn't expect unwinding. Either way, you are multiplying complexity for generic code. (Not to mention you have to invent a whole new set of idioms for panic-free code.)

* You still have to be able to clean up the resources held by a caller that does expect unwinding. So all your vocabulary/glue/library code (the stuff that can't just assume panic=abort) still needs these "scoped panic hooks" in all the same places it has any level of panic awareness in Drop today.

So for anyone to actually benefit from this, they have to be writing panic-free code with whatever new static or dynamic tools come with this, and they have to be narrowly scoped and purpose-specific enough that they could essentially already today afford panic=abort. Who is this even for?

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

#133

Post by writebetterc »

pizlonator wrote: post #66
writebetterc wrote: post #25

Earlier quoted context omitted.

This is very similar to how Java's object monitors are implemented. In OpenJDK, the markWord uses two bits to describe the state of an Object's monitor (see markWord.hpp:55). On contention, the monitor is said to become inflated , which basically means revving up a heavier lock and knowing how to find it. I'm a bit disappointed though, I assumed that you had a way of only using 2 bits of an object's memory somehow, b…

The lock takes two bits. It’s just that if you use the WTF::Lock class the. You get a full byte simply because the smallest possible size of a class instance in C++ is one byte. But there’s a template mixing thing you can use to get it to be two bits (you tell the mixin which byte to steal the two bits from and which two bits). I suspend the same situation holds in the Rust port. I am very familiar with how Java does…

>I am very familiar with how Java does locks. This is different. Look at the ParkingLot/parking_lot API. It lets you do much more than just locks, and there’s no direct equivalent of what Java VMs call the inflated or fat lock. The closest thing is the on demand created queue keyed by address.

Are you familiar with the new LightweightSynchronizer approach with an indirection via a table, instead of overwriting the markWord? I'd say that this has pushed the ParkingLot approach and Java's (Hotspot's, really) approach closer to each other than before. I think the table approach in Java could be encoded trivially into ParkingLot API, and the opposite maybe. Obviously the latter would be a lot more hamfisted.

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

#134

Post by JoshTriplett »

Rusky wrote: post #132
JoshTriplett wrote: post #131

Earlier quoted context omitted.

The difference is that unwinding unwinds code that isn't necessarily prepared for it, rather than only code that explicitly wants it. And I would expect to turn it into an efficient solution, in part by doing the "store in a side table" approach for hook registration.

Giving special treatment to code that "explicitly wants" to handle unwinding means two things: * You have to know when an API can unwind, and you have to make it an error to unwind when the caller isn't expecting it. If this is done statically, you are getting into effect annotation territory. If this is done dynamically, are essentially just injecting drop bombs into code that doesn't expect unwinding. Either way, y…

To be very explicit about something: these are all vague design handwaves, and until they become not only concrete but sufficiently clear to handle use cases people have, they're not going to go anywhere. They're vague ideas we're thinking about. Right now, panic unwind isn't going anywhere.
Post reply on HN