Implementing Hazard Pointers in Rust

Показать описание

0:00:00 Introduction
0:00:37 Rust for Rustaceans
0:01:00 Concurrent Memory Reclamation
0:10:32 Hazard Pointers
0:35:27 Folly's Hazard Pointer Interface
0:54:08 Delayed Reclamation
0:58:18 More Folly Interface
1:11:56 A Wild Entity Diagram Appears
1:16:40 Memory Use
1:21:12 More Folly Interface
1:27:50 Starting the Rust Code
1:35:24 Testing Out the Rust Interface
1:42:32 HazPtrHolder::load
2:02:15 HazPtrObject::retire
2:19:43 HazPtrHolder::reset
2:22:50 Unsafe Blocks in Unsafe Fns
2:25:04 Borrow Checker Prevents Misuse
2:27:45 Bad Drop Lint
2:34:15 Dropping in HazPtrDomain::retire
2:46:00 Intermission
2:47:57 Reading Folly's HazPtrDomain::retire
2:59:02 HazPtrDomain::acquire
3:17:32 HazPtrDomain::retire
3:45:57 Specifying a Deleter
4:32:26 Tests Pass?
4:36:12 Eager Reclaiming
4:37:32 Checking Reclamation Behavior
4:52:04 Final Thoughts

Рекомендации по теме

Комментарии

Just so it's clear, deleter is a standard C++ pattern roughly equivalent to the allocator proposal, and default_delete<T> is basically Drop. Not exactly, as destruction and freeing is more explicitly separate in C++, so deleters both destroy the target of and frees the pointer, while in rust those are done separately by, say, Drop for Box.

SimonBuchanNz

I've watched a couple of Andrei Alexandrescu talks and I think he is a brilliant person. Thank you for taking me through some of his work!

nyanjuigitau

Oh, I didn't know you were writing a book. With help from dtolnay no less! Prestigious stuff! I will buy it as soon as I can, I absolutely love your content, I just wish I had more time to sit down and carefully go through all of it.

robinmattheussen

Wonderful stuff as always Jon :D I'll be getting your book for sure. As someone who works with concurrency problems regularly, these videos are highly appreciated.

franksinatra

damn bro i did not understand most of the things you were talking about in the first 5 min itself but its really good to have resources like this but I have gaps in my knowledge to get the things you are teaching.

vamshikrishnareddy

Do hazard pointers give you "if it compiles, then it works" level certainty, or "if you use them correctly, then they'll work" level certainty? Seems like the former.

CarrotCakeMake

Heh, it took me a few minutes, but I remembered reading the original article in CUJ when it came out. You can count on Andrei Alexandrescu for clever solutions like that.

eclecticaaronbentley

Just started watching this and not sure if anyone asked or if it came up but was wondering, the writers have to check eventually to see if the hazard LL is empty after it made its CAS, but my question is, couldn't this be made wait-free in a way, if the writer doesn't wait, and instead the reader does the cleanup when it's done?

Can't the reader before it clears it hazard, check the original atomic, and if it no longer points to the held address, then the reader checks if it's the last user in the LL and if so then it does the reclamation, maybe this is explained later :X Just seemed like a possibility existed, i mean the hazard LL would have to hold both addresses (atomic location + actual data location)?

cchance

So when I look at std::mem::drop, it doesn't look like the T generic type has bounds on being Drop, so you should be able to throw a *mut dyn Any I'd think. Unless something special happens when you make a dyn Drop to ensure rust knows how to drop it *with its own impl*

keldwikchaldain

Could you implement this with async await... Or would it create greater overhead?

fitFix

Why youtube does't generate subtitle for your last two videos?

ianzhu

You mention at 49:00 that you can't write an extension trait that adds fields. Can't you, although difficultly, use a proc macro of some sort? Sometimes I think something is impossible then some proc macro wizard makes something insane work. For example in the backend framework Rocket, the docs recommend this signature for main:

#[launch]
fn rocket() -> _ {}

driedurchin