Real-world Concurrency Reading notes

article name: Real-world Concurrency
Links: http://queue.acm.org/detail.cfm?id=1454462
As the article is the field of many years of experience in the summary, there are many local understanding is not deep enough, can only write their own understanding.
The article first introduces and publishes the history: the only goal to improve the concurrency of the system is to improve performance. Three ways to improve performance with concurrency: Reduce, hide latency, and increase throughput.
The following is a list of recommendations:
Recommendation 1: Identify the hot and non-hot paths of the system and treat them differently. For non-hotspot paths, don't spend too much time on concurrency: The effects are not good and error-prone. About error prone, the system's non-hotspot path is often difficult to implement concurrency and error-prone code (such as Start, initialize)

Recommendation 2: Data speak, intuition is not necessarily reliable. Getting data is not easy: building a hardware and software environment. A powerful system dynamic performance analysis tool is required in the software environment.

Recommendation 3: Carefully weigh the handling of large locks. Transforming a global lock into a PER-CPU lock, lock hash table, single-struct lock looks cool, but sometimes it's wiser to hold a large lock in time by shortening it.

Recommendation 4: A trap for reading and writing locks. When there is a read-write-less lock, intuitively tend to transform into a read-write lock, when the lock holding time is not a long time, whether this can improve concurrency (extensibility) is debatable, carefully evaluated.

Recommendation 5: Adopt a PER-CPU lock. Two recommendations: Considering the complexity of the implementation, the use of PER-CPU locks also requires hot-spot analysis data support; Keep locks in the same order to avoid deadlocks.

recommendation 6: Weigh the right broadcast, when to use signal
Recommendation 7: Learn to analyze afterwards. such as using Coredump to find problems.
recommendation 8: Design the system into modular (modularized). Modularity and lock/condition variables can coexist and are implemented in two ways: by restricting the lock/condition variable inside the subsystem and without locking it.
recommendation 9: Do not use semaphore when the mutex satisfies the requirements.
recommendation 10: Adoptmemory retiring to implement per-chain hash table lock. When it is necessary to parallelize the hash tableaccess, you can use the Per-chain lock.
recommendation 12: Avoidfalse Sharing.
recommendation 13: Use synchronous non-blocking functions to monitor race conditions.
Recommendation 14: If not necessary, do not waitfree and lockfree skills.
Recommendation 15: Always keep a heart in two preparations. It is difficult to know whether the concurrency problem currently being resolved is the last one.

Real-world Concurrency Reading notes