Multiple ChoiceHard 45s
shared_ptr lock-free progress hazard
Why do lock-free data structures pose a hazard when managed by std::shared_ptr reference counting?
Options
- 1shared_ptr is not copyable, so lock-free algorithms cannot share ownership safely
- 2shared_ptr cannot be used with atomics, so its reference count is inherently single-threaded
- 3The internal refcount is not lock-free for a wait-free forward progress guarantee
- 4the reference counts overflow after 255 shared owners, corrupting the control block
Think you can answer under pressure?
Get matched and answer live questions in 3-minute 1v1 battles. Elo ranking, badge tiers and bragging rights on the line.