Changes for page Concurrency

Summary

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

Details

Page properties

Content

...	...	@@ -10,6 +10,52 @@
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	+
13	13	### Problems of testing multi-threaded methods
14	14
15	15	* Very tricky which is why concurrency should be avoided in the first place.