{"action":"opened","issue":{"url":"https://api.github.com/repos/rphmeier/rust_toy_engine/issues/38","labels_url":"https://api.github.com/repos/rphmeier/rust_toy_engine/issues/38/labels{/name}","comments_url":"https://api.github.com/repos/rphmeier/rust_toy_engine/issues/38/comments","events_url":"https://api.github.com/repos/rphmeier/rust_toy_engine/issues/38/events","html_url":"https://github.com/rphmeier/rust_toy_engine/issues/38","id":129233808,"number":38,"title":"Look into concurrency primitives other than RwLock","user":{"login":"rphmeier","id":10121380,"avatar_url":"https://avatars.githubusercontent.com/u/10121380?v=3","gravatar_id":"","url":"https://api.github.com/users/rphmeier","html_url":"https://github.com/rphmeier","followers_url":"https://api.github.com/users/rphmeier/followers","following_url":"https://api.github.com/users/rphmeier/following{/other_user}","gists_url":"https://api.github.com/users/rphmeier/gists{/gist_id}","starred_url":"https://api.github.com/users/rphmeier/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rphmeier/subscriptions","organizations_url":"https://api.github.com/users/rphmeier/orgs","repos_url":"https://api.github.com/users/rphmeier/repos","events_url":"https://api.github.com/users/rphmeier/events{/privacy}","received_events_url":"https://api.github.com/users/rphmeier/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-01-27T18:53:29Z","updated_at":"2016-01-27T18:53:29Z","closed_at":null,"body":"RwLocks are notoriously bad, even though they seem like a good solution.\r\nhttps://blogs.oracle.com/roch/entry/beware_of_the_performance_of\r\n\r\nA single, naive mutex is out of the question as far as contending for the world state goes, although you probably could come up with a way to split up resources.\r\n\r\nThere are three levels of locking which must be considered:\r\n  1) Read-only. Any number of threads may safely read the state at the same time. \r\n  2) Modifying existing components, but not adding new ones.\r\n  3) Adding and removing components is the highest level of locking. This can reallocate backing storage for components, so any processor doing this must have completely exclusive access.\r\n\r\nTo facilitate these three cases, we can probably come up with an RwLock-like implementation using a few mutexes and atomic counters, specialized for this use case.\r\n\r\nFor cases where we modify existing components, we could have a lock for each one. Processors can acquire them to enjoy exclusive access to that particular component's storage while not inhibiting other processors from accessing other components stored in the blob. This approach is prone to deadlock if two threads attempt to acquire unique access to multiple components in a different order. The standard method of avoiding mutex deadlock is to have a total order in which mutexes must be locked. We may be able to use the recursive nature of the implementation of the components trait to achieve this naturally."}}