Concurrency

𝔇𝔢𝔱𝔢𝔯𝔪𝔦𝔫𝔦𝔰𝔱𝔦𝔠 𝔰𝔦𝔪𝔲𝔩𝔞𝔱𝔦𝔬𝔫 𝔱𝔢𝔰𝔱𝔦𝔫𝔤 deterministic: of or relating to a process or model in which the output is determined solely by the input and initial conditions, thereby always returning the same results ( stochastic ): The algorithms are simple and deterministic, so the results are predictable and reproducible. Example based testing Example based testing works fine for simple cases where there’s only a small number of actions that matter. let%test_unit "append entries: truncates the log on entry conflict" = let storage = make { dir = Test_util.temp_dir () } in (* Leader adds some entries to the replica's log. *) append_entries storage (last_log_index storage) [ { term = 1L; data = "1" }; { term = 2L; data = "2" }; { term = 3L; data = "3" }; ]; (* Another leader overrides the replica's log. *) append_entries storage 2L [ { term = 4L; data = "3" }; { term = 4L; data = "4" } ]; assert (entry_at_index storage 1L = Some { term = 1L; data = "1" }); assert (entry_at_index storage 2L = Some { term = 2L; data = "2" }); (* Entry at index 3 has been overwritten. *) assert (entry_at_index storage 3L = Some { term = 4L; data = "3" }); (* Entry at index 4 is new. *) assert (entry_at_index storage 4L = Some { term = 4L; data = "4" }) It becomes way harder to think of and write the examples when the bugs you’re looking for only happen after several events that need to happen in a specific order. ...

A deadlock happens when there’s at least one resource that can be only acquired by one process at a time and there’s a process P1 that is waiting to acquire a resource currently held by a process P2 and P2 is waiting to acquire a resource currently held by P1. The word process does not mean we are talking about just OS processes. There are two processes: Process A wants to acquire a lock on resource 1 and then a lock on resource 2. Process B wants to acquire a lock on resource 2 and then a lock on resource 1. ...

Anomalies An anomaly or read phenomena can happen when a transaction reads data that may have been modified by another concurrent transaction. Dirty read A dirty read happens when a transaction T1 reads data that has been modified by a concurrent transaction T2 that has not has been committed or rolled back yet. T1 ends up working with stale data if T2 does not commit. T2 starts executing and sets x to a new value, T1 starts executing and reads x, the value of x is the value just set by T2, T2 rolls back, the value of x is not persisted to the database but T1 will move forward with the stale value of x that was written before T2 rolled back. ...

The problem You are developing an application backed by a database, something happens and then several of your users try to access the same content. Several requests are sent to your backend at almost the same time and your backend hits the database once for each request to fetch the same data. Fetching the data only once If N requests asking for the same data arrive at the backend at around the same time, the backend could hit the database to fetch the data when the first request arrives and force the other requests to await until the data is fetched. When a response to the request sent to the database arrives at the backend with the data, the data can be shared with the requests that are waiting for it. ...

Uber has adopted Go as its primary programming language for developing microservices and has a post on its blog called Data Race Patterns in Go where they talk about data races found in their Go codebase. I was reading it and thought to myself that many of the problems presented in the post would not even compile in Rust. Can Rust help us avoid writing code with common data races? Examples written in Rust are not meant do be idiomatic Rust and do not wait for outputs generated by tasks for simplicity because the examples written in Go do not wait as well. ...