ConcurrencySprint 1SuccessOverall ObjectivesCompiled Learning ObjectivesThreads and ConcurrencyExplain why we use concurrency.Explain why web applications are concurrent by default.Define a race condition.Memory ModelsSuggest orders of magnitude for the speed of different read operations.Intro ReadingDefine concurrency.Differentiate between parallelism and concurrency.Start multiple concurrent threads of execution (either threads or goroutines).(If in Go): Define a channel.(If in Go): Send information between goroutines using a channel.Single-variable ConcurrencyIdentify thread safety issues when updating a single variable.Explain how += operations can cause bad writes in the presence of threads.Describe (at a high level) three approaches to fixing single-variable thread-safety issues.AtomicsDefine an atomic operation.Use an atomic operation to avoid a race condition when modifying an integer.Explain how an atomic operation avoids a read-modify-write race condition.Define the term ‘memory barrier’/‘fence’ in the context of memory models.MutexesSolve a race condition with a mutex.Define a critical section.Identify the critical section in concurrent code.Explain the risks of mis-identifying the critical section, and releasing locks early.Choose between using mutexes and atomics.DeadlockDefine deadlock.Identify causes of deadlock in code.Re-entranceDefine re-entrance.Explain how a re-entrant lock can avoid deadlock.Identify sources of deadlock when using non-re-entrant locks.Project: Cache with StatsImplement thread-safe code.Optimising LocksEvaluate trade-offs between using a mutex and a read-write mutex.Shard locks to reduce contention.Propose the trade-offs of loosening API guarantees.Computing CacheAvoid concurrency problems with message passing instead of locking.Comparing ImplementationsIdentify trade-offs in different code implementing the same interface.Evaluate the expense of operations in code.Identify sources of lock contention in code.