I noticed the example image: "It looks like this method needs to use the read lock because it's accessing the `dataKeys` map. I would recommend documenting whic

I noticed the example image: "It looks like this method needs to use the read lock because it's accessing the `dataKeys` map. I would recommend documenting which methods are and are not meant to be safe for concurrent access." To me, this is a problem addressed by Rust's &/&mut separation, which can be imitated in other languages (eg. in multithreaded code, wrap types in Mutex<T>/MutexGuard<T> or RwLock<T> with read guards lending out `const T&` and write guards lending out `T&`, if you're in a language without const, tough luck). This creates code which self-documents concurrency in the type system like Rust, though it's less watertight since you can hold onto references for too long.