A fascinating design decision of Hashtable in .NET is its support for multiple readers AND a single writer.<p>In C++ or Rust, we get multiple readers OR a single writer. Shared ref or exclusive mut, pick one. But in .NET we have AND not OR: one writer AND multiple readers, all concurrent.<p>This works because .NET's GC can tolerate the race. A writer may trigger a table rehash, and a reader will read either the old or new table. If the reader loads the old table, it won't be deallocated until it's done: the GC will keep it alive.<p>Any cool uses of this one writer AND multiple readers?<p><a href="https://learn.microsoft.com/en-us/dotnet/api/system.collections.hashtable" rel="nofollow noreferrer">https://learn.microsoft.com/en-us/dotnet/api/system.collecti...</a>
From the article: std::map inserts are O(log n) while std::unordered_map inserts are O(1) and rehashes are O(n). Concurrent rehashes have a high chance of crashing, but I don't see how it follows that overall unordered_map crashes more than std::map.<p>Maybe it's beacause std::map tree nodes don't get reallocated while unordered_map hash buckets do ?
Crashed a lot... more? You tell me crashing was expected default behaviour to a point where the suitability of implementation details was decided by how much one would crash?
I wonder why he felt the need to reiterate the obvious here twice, about concurrent read/write being the true culprit. I mean, it's already obvious from the title that this is just an intellectual pursuit to satisfy some curiosity. Is it really that weird or unconventional of a question?
Anyone making multithreaded code in c++ should be using thread sanitizer. Whether or not a specific datastruture crashes more in multithreaded code will not matter, since tsan will issue a warning on all unsafe accesses.
I’m stunned that this article exists and was published by Microsoft. Unsafe access to either is clearly undefined behavior. Discussing which one is more or less undefined is like discussing whether it’s safer to run with scissors or a knife: it doesn’t really matter because you’re going to cut yourself badly and possibly in life-changing ways.<p>Please protect your STL data structures with a mutex. Please keep your thread communications sane. There’s no reason to think through why one is more prone to explosion than another; any conclusions you draw are at best only relevant to your current compiler and STL implementation, and maybe only during some phases of the moon.
Given that “crash” in C++ has a 99% chance to mean “security issue”, and given that I have seen people “pragmatically” go with a solution that “crashes less” in the wild, I’m convinced that nothing good comes out of this line of reasoning.