Changes for page Concurrency

Summary

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

Details

Page properties

Content

...	...	@@ -30,22 +30,19 @@
30	30	* **Libraries**: Use the thread-safe collections provided. Use non-blocking solutions if possible. Be aware multiple library classes are not thread safe.
31	31	* **Concepts**: Mutual Exclusion, Deadlock, Livelock, Thread Pools, Semaphore, Locks, Race Condition, Starvation,
32	32	* **Patterns**: Producer-consumer, Reader-Writer
33		-* **Algorithms**: Study common algorithms and their use in solutions. For example, the Dining Philosophers problem.
	33	+* **Algorithms**: Study common algorithms and their use in solutions. For example, the Dining Philosophers problem.
34	34
35		-### Watch out for dependencies between synchronized methods
	35	+### Synchronized Methods
36	36
37		-* **Avoid dependencies between synchronized methods**: Synchronized means that only one thread can access a method at a time. In concurrent code, such dependencies, such as when one synchronized method calls another, can cause subtle bugs like deadlocks and performance issues.
	37	+Synchronized means that only one thread can access a method at a time.
	38	+
	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.
38	38	* **Avoid applying more than one method to a shared object.** If this is not possible, you have three options:
39	39	* **Client-based locking**: The client locks the server, calls all the server methods, and then releases the lock.
40	40	* **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.
41	41	* **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.
42		-* **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 problems.
	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	43
44		-### Writing correct shutdown code is difficult
45		-
46		-* You should think about a shutdown as early as possible and get it running as soon as possible. If you wait, it will always take longer. Study the available algorithms because this task is probably harder than you think.
47		- * TODO: Why do I need shutdown code?
48		-
49	49	Some Notes:
50	50
51	51	* When I/O is the bottleneck of your application, more threads will increase the performance in opposite to when CPU is the bottleneck.
...	...	@@ -59,3 +59,4 @@
59	59	* Client-based locking: User has to manually implement locking. This approach error prone and hard to maintain.
60	60	* 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.
61	61	* As little synchronized code (`synchronized`) as possible should be used. And if, then only for small, critical code sections.
	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.