concurrent-hash-map
| Crates.io | concurrent-hash-map |
| lib.rs | concurrent-hash-map |
| version | 0.0.6 |
| source | src |
| created_at | 2016-03-06 20:48:30.206712 |
| updated_at | 2016-09-18 14:37:01.506433 |
| description | This is a simple concurrent hash map written in Rust. It uses a design where read operations never lock against reads or writes, but writes can sometimes lock against other writes. In order to maintain concurrency on insert/removal operations, the map is segmented into several sub-maps, each of which has its own write lock. This code is currently extremely pre-alpha. Most particularly, it leaks memory on table growth and drop, as well as when using keys or values that (even transitively) use custom Drop implementations. It should be possible to fix this, but a clean solution will require support for running destructors in crossbeam (see crossbeam issue #13). For now it may be useful for long lived hashmaps with a relatively steady size, but I don't recommend using it for anything important :-). |
| homepage | |
| repository | https://github.com/AlisdairO/concurrent-hash-map |
| max_upload_size | |
| id | 4386 |
| size | 28,629 |
Alisdair Owens (AlisdairO)
documentation
README
This is a simple concurrent hash map written in Rust. It uses a design where read operations never lock against reads or writes, but writes can sometimes lock against other writes. In order to maintain concurrency on insert/removal operations, the map is segmented into several sub-maps, each of which has its own write lock.
This code is currently extremely pre-alpha. Most particularly, it leaks memory on table growth and drop, as well as when using keys or values that (even transitively) use custom Drop implementations. It should be possible to fix this, but a clean solution will require support for running destructors in crossbeam (see crossbeam issue #13).
For now it may be useful for long lived hashmaps with a relatively steady size, but I don't recommend using it for anything important :-).