6 points
*

@Arbitrary I did this a while ago, you might find it useful. It abandons the more traditional vector concept of sequential insert, so that remove() can be implemented. https://github.com/Alonely0/Lariv

permalink
report
reply
3 points

Neat work, I’ll be sure to take a peek later.

permalink
report
parent
reply
2 points

chunks: [AtomicPtr>; 64], appears before the explanation of why 64 works, and was confusing at first glance since this is completely different than the previous use of 64, which was arbitrary. I was expecting a variable-size array of fixed-size arrays at first (using something like an rwlock you can copy/grow the internal vector without blocking - if there was a writer, the last reader of the old allocation frees it).

Instead of separate flags, what about a single (fixed-size, if chunks are) atomic bitset? This would increase contention slightly but that only happens briefly during growth, not accesses. Many architectures actually have dedicated atomic bit operations though sadly it’s hard to get compilers to generate them.

The obvious API addition is for a single thread to push several elements at once, which can be done more efficiently.

permalink
report
reply

Rust

!rust@programming.dev

Create post

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits
  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

Community stats

  • 572

    Monthly active users

  • 887

    Posts

  • 3.9K

    Comments