Changes for page Concurrency

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -17,7 +17,7 @@
17	17	### Defensive Concurrency Programming
18	18
19	19	* **Single-Responsibility Principle**
20		- * **Separation of code**: Changes to concurrent code should not be mixed with changes to the rest of the code. Therefore, you should separate the source code of sequential and concurrent code.
	20	+ * **Separation of code**: Changes to concurrent code should not be mixed with changes to sequential code. Therefore, you should separate the source code of sequential and concurrent code.
21	21	* **Separation of change**: Concurrent code has special problems that are different, and often more serious, than sequential code. This means that concurrent and sequential code should be changed separately, not within the same commit, or even within the same branch.
22	22	* **Principle of Least Privilege**: Limit concurrent code to the resources it actually needs to avoid side effects. Minimize the amount of shared resources. Divide code blocks and resources into smaller blocks to apply more granular, and therefore more restrictive, resource access.
23	23	* **Data Copies**: You can sometimes avoid shared resources by either working with copies of data and treating them as read-only, or by making multiple copies of the data, having multiple threads compute results on them, and merging those results into a single thread. It is often worth creating multiple objects to avoid concurrency problems.
...	...	@@ -46,7 +46,7 @@
46	46
47	47	### Miscellaneous
48	48
49		-* **Performance**: When a performance bottleneck is detected in an application, the cause can be I/O or CPU. Increasing the number of threads will show which of the two is the actual bottleneck, see [[this article|doc:Software Engineering.Testing.Enhance Test Execution Speed.WebHome]].
	49	+* **Performance**: When a performance bottleneck is detected in an application, the cause can be I/O or CPU. Increasing the number of threads will show which of the two is the actual bottleneck, see [[this article|doc:Software Engineering.Testing.Test Speedup.WebHome]].
50	50	* **Stress Testing**: A common type of test that determines the maximum throughput of an application by sending a large number of requests and examining the response times.
51	51	* **Execution Paths**: Always consider the concept of different execution paths. The amount of possible interleaving of instructions that are processed by at least two threads. For example, objects with mutable states could unintentionally cause different results doing the same operation twice.
52	52	* **Write Shutdown Code Early**: Shutting down an application requires the safe termination of all concurrent processes. Writing shutdown code is difficult. Writing shutdown code early is cheaper than writing it later. Study the available algorithms.