{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigc7ze2xqmtdzhrp4x6di27jspszg6gor3rv2dqbdub6g6uijupiy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mgdsxe56qd42"
  },
  "path": "/t/idea-lock-free-std-collection/24056#post_5",
  "publishedAt": "2026-03-05T19:59:07.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "fuji-184:\n\n> Lock free performance is generally superior\n\nIs it?\n\nLock-free implies these collections are supposed be mutably shared across threads, but mutable sharing itself can be a source of performance problems. No matter how you do locking (or not - see false sharing), you can still have performance penalty from writing to memory cached across cores.\n\nThere are many possible trade-offs for mutably-shared collections, and I wouldn't say they're faster, but rather you can choose which workloads are least slowed down by the sharing.\n\nYou can make collections that tolerate higher concurrency when writing or appending, but this usually comes at a cost of slower reads and pointer chasing.\n\nOr you can design for mostly-immutable collections that only need an occasional write, by using optimistic locking (and still call it lock-free because it uses spinlocks or swaps pointers to copies).\n\nAnd there's the special case of wait-free (for guaranteed latency, usually at the cost of everything else), and a subset of that which is signal-safe where you literally can't use locks.\n\nIt's not a \"generally superior\" upgrade. It's a bunch of tricky problems with different costs and downsides, highly dependent on the workload. If you make some middle-of-the road universal collection, it may end up being inferior in every workload compared to more specialized implementations.\n\nWhat's the use-case? What do you need interoperability with, and why by sharing a specific collection type and not a channel, callback, or an implementation hidden behind a trait?",
  "title": "Idea : Lock Free STD Collection"
}