# Libs Meeting 2022-01-12

###### tags: `Libs Meetings` `Minutes`

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-ujepnbwg2lzqgt6wvrndwimi
**Attendees**: Amanieu, Jane, Josh Triplett, Mark, The 8472, Mara

## Agenda

- [Open Action Items](https://hackmd.io/Uehlc0qUQfWfvY1swYWRgQ)
- Triage
- Empty today!
- Amanieu: Std's and parking_lot's mutexes and condition variables
- Anything else?

## parking_lot: Mutexes and Condvars

Amanieu presents "parking lot in the standard library":





Questions:

- Do we want this on Windows too? Windows' SRW locks are very small and efficient already. (And movable and const-constructible and don't need drop.)
- Writer starvation behaviour? Writers are prioritized.
- We already use SRW locks in std.
- Upgradable reader-writer locks? Parking lot has support for that, but it's often mis-used.
- Only downside is that it can't be inlined.

- Do we want this on Linux/BSD instead of something directly built on futex() (or WaitOnAddress on Windows)?
- possible, but those have fewer features
- you couldn't know if you were the last one in the queue, always requiring a syscall.
- fairness? we don't care about that. fairness slows things down and is often not what you want.
- Letting the kernel manage the queue has the advantage that we don't have to deal with the scalability of the user space queue. And the kernel has a better overview of who is waiting for what, priority inversion handling etc.
- Downside is that it's more code if we use parking_lot for other platforms and have a different linux/bsd implementation.
- If you're running tens of thousands of threads on 800 cpus or something, you're most likely on Linux (or BSD or Windows). Letting the kernel handle the scaling can be good. And then all other platforms can use a fixed-size table.

- What's the relation with `std::thread::park()` and `std::thread::Thread.unpark()`?
- The part with the callbacks, keys, etc. will not be public. That's much lower level.

- `parking_lot_core::thread_parker::*` is pretty close to std's `park()` and `unpark()`. Should that be identical and reused?

- Global chaining hash table for lock addresses. How is resizing handled?

- Worst case behaviour of the hash table?
- Traversing a long linked list. But unlikely.

- Bypassing pthread/libc, does that upset anyone/anything?
- We'd not be the first ones to ship our own non-pthread locks.
- Valgrind?
- We should add the relevant annotations.

- Mark: Make sure that we still test the non-futex version on Linux in CI.