7 ms·
I would argue that "the table" is not mutated, only the internal state of its implementation. Every time you access any information, a cache at some layer below
by btym 7y ago
I would argue that "the table" is not mutated, only the internal state of its implementation. Every time you access any information, a cache at some layer below you is updated. Is that also gross?
- cperciva 7y agoYes. Normally you can have one thread writing to a data structure OR many threads reading the data structure at any given time and not need to worry about them causing problems. (This situation is common enough that we have things called "reader-writer mutexes" or "shared-exclusive" mutexes.) As soon as your reads can modify the internal state of the data structure, it might modify the state in a way which trips up another read; so you can no longer have many threads reading the data structure at once.
- btym 7y agoThat's a great point. It's still a possible optimization with a compare-and-swap or if you can determine that you're in a single threaded context.
- pcwalton 7y agoRight. And in Rust implementing the hash table that way will suddenly make the table no longer flagged as "Sync" by the compiler, so you will be unable to share it between threads.
- deleted 7y ago[deleted]
- shittyadmin 7y agoBut you don't need to write every time, only on occasion, so you can actually use a read write lock and in the nominal case many threads can read just fine. That said, it's probably still better to avoid this unless it's absolutely necessary to modify the underlying structure sometimes, I recently had to do this for an LRU cache.