Changes for page Concurrency

Summary

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

Details

Page properties

Content

...	...	@@ -10,52 +10,6 @@
10	10	* 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.
11	11	* As little synchronized code (`synchronized`) as possible should be used. And if, then only for small, critical code sections.
12	12
13		-### Prevent Deadlocks
14		-
15		-* Do this by making one of its four conditions impossible.
16		-
17		-### Mutual Exclusion (Mutex)
18		-
19		-* Description:
20		- * When resources can't be used by mutual thread and
21		- * there are less resources than threads.
22		-* Solutions:
23		- * Use concurrently accessible resources like AtomicInteger.
24		- * Increase the number of resources until its greater or equal to the number of competing threads.
25		- * Check if every required resource is accessible before the task starts.
26		-
27		-### Lock & Wait
28		-
29		-* Description:
30		- * Once a thread acquires a resource, it will not release the resource until it has acquired all of the other resources it requires and has completed its work.
31		-* Solutions:
32		- * Before reservation of a resource, check its accessibility.
33		- * If a resource is not accessible, release every resource and start from anew.
34		-* Dangers:
35		- * Starvation: A thread never achieves to reserve all required resources.
36		- * Livelock: Thread gets tangled up.→ This approach is always applicable but inefficient as it causes a bad performance.
37		-
38		-### No preemption
39		-
40		-* Description:
41		- * A thread is unable to steal a resources reserved by another thread.
42		-* Solution:
43		- * A thread is allowed to ask another thread to release all of its resources (including the required one) and starting from anew. This approach is similar to the 'Lock & Wait' solution but has a better performance.
44		-
45		-### Circular Waiting / Deadly Embrace
46		-
47		-* Description:
48		- * When two or more threads require a resource which is already reserved by another of these threads.
49		- * Example:
50		- * Thread T1 has resource R1 and waits for R2 to be released.
51		- * Thread T2 has resource R2 and waits for R1 to be released.
52		-* Solution:
53		- * All threads reserve all resources in a the same order.
54		-* Problems:
55		- * The order of reservation doesn't necessarily have to be the same as the order of usage. This leads to inefficiencies like reserving a resource at the beginning which is just required at the end of the task.
56		- * Unnecessarily long locked resources.
57		- * Order can not always be specified.
58		-
59	59	### Problems of testing multi-threaded methods
60	60
61	61	* Very tricky which is why concurrency should be avoided in the first place.