Changes for page Concurrency

Summary

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

Details

Page properties

Content

...	...	@@ -34,26 +34,20 @@
34	34
35	35	### Synchronized Methods
36	36
37		-Synchronized means that only one thread can access a method at a time.
	37	+Synchronized means that only one thread can access a method at a time to prevent side effects.
38	38
39	39	* **Avoid dependencies between synchronized methods**: In concurrent code, such dependencies, such as when one synchronized method calls another, can cause subtle bugs like deadlocks and performance issues.
40	40	* **Avoid applying more than one method to a shared object.** If this is not possible, you have three options:
41	41	* **Client-based locking**: The client locks the server, calls all the server methods, and then releases the lock.
42	42	* **Server-based locking**: Create a method in the server that locks the server, calls all the methods, and then unlocks the server. A client can now safely call this new method.
43		- * **Adapted Server**: Create an intermediate component to perform the lock. This is a variant of server-based locking when the original server cannot be changed.
44		-* **Keep synchronized sections small.** Locks are expensive because they add administrative overhead and delay. On the other hand, critical sections need to be protected. Critical sections are pieces of code that will only run correctly if they are not accessed by multiple threads at the same time. Keeping synchronized sections small avoids both problem
	43	+ * **Adapted Server**: Create an intermediate component to perform the lock. This is a variant of server-based locking when the original server cannot be changed. Ideally, one would use thread-save collections and implements them behind extended interfaces.
	44	+* **Server-based locking is preferred over client-based locking.** With server-based locking, the class used takes care of the internal locking, so the user has nothing else to worry about. With client-based locking, the user has to implement locking manually, which makes the approach error-prone and difficult to maintain.
	45	+* **Keep synchronized sections small.** Locks are expensive because they add administrative overhead and delay. On the other hand, critical sections need to be protected. Critical sections are pieces of code that will only run correctly if they are not accessed by multiple threads at the same time. Keeping synchronized sections small avoids both problem. Only use it for small, critical code sections.
45	45
46		-Some Notes:
	47	+### Miscellaneous
47	47
48		-* When I/O is the bottleneck of your application, more threads will increase the performance in opposite to when CPU is the bottleneck.
49		-* Stress Testing: Checking the throughput of an application by sending a huge amount of requests and examining the response times.
50		-* Isolate concurrent code by putting it in a few separate classes.
51		-* Always consider the concept of 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		-* Atomic operation = operation which can not be interrupted by other threads. But for unsynchronized processes threads can put instructions between two atomic operations.
53		-* `synchronized` prevents unintended side-effects.
54		-* Server-based locking is preferred over client-based locking.
55		- * Server-based locking: The class used takes care of internal locking, so the user has nothing else to worry about.
56		- * Client-based locking: User has to manually implement locking. This approach error prone and hard to maintain.
57		-* If there is no access to the server an adapter class can be used instead. Even better would be thread-save collections using extended interfaces.
58		-* As little synchronized code (`synchronized`) as possible should be used. And if, then only for small, critical code sections.
	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]].
	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	+* **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	+*
59	59	* **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.