Changes for page Concurrency

Summary

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

Details

Page properties

Content

...	...	@@ -45,12 +45,15 @@
45	45	* Deadlock
46	46	* Livelock
47	47	* Thread Pools
48		- * Runnable
49		- * Callable
50	50	* Future
51		- * Java Executor Framework
	49	+ * Synchronization: General term for techniques that control the access of multiple threads to shared resources.
	50	+ * Race Condition: A situation where the system's behavior depends on the relative timing of events, often leading to bugs.
	51	+ * Semaphore: An abstract data type used to control access to a common resource by multiple threads.
	52	+ * Locks: Mechanisms to ensure that only one thread can access a resource at a time.
	53	+ * Atomic Operations: Operations that are completed in a single step relative to other threads.
	54	+ * Thread Safety
52	52	* Producer-consumer
53		- * Reader-recorder
	56	+ * Reader-recorder vs Reader Writer??
54	54	* Philosopher problem → Study algorithms and their application in solutions.
55	55
56	56	### Watch out for dependencies between synchronized methods
...	...	@@ -83,22 +83,3 @@
83	83	* Client-based locking: User has to manually implement locking. This approach error prone and hard to maintain.
84	84	* 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.
85	85	* As little synchronized code (`synchronized`) as possible should be used. And if, then only for small, critical code sections.
86		-
87		-### Problems of testing multi-threaded methods
88		-
89		-* Very tricky which is why concurrency should be avoided in the first place.
90		-* In general this requires a lot of iteration which makes it resource intensive.
91		-* The outcome is architecture dependent (OS, hardware) which introduced randomness and make the error detection unreliable.
92		-
93		-### Solution approaches for testing multi-threaded methods
94		-
95		-* Monte-Carlo-Tests
96		- * Write flexible, adaptive tests.
97		- * Repeatedly run them on a test server and randomly vary the test settings.
98		- * If something fails, the code is defect and the applied settings should be logged.
99		- * Do this early to gain tests ASAP for your testing repertoire or CI-server.
100		-* Execute these tests on every platform over a long time to increase the probability that
101		- * the production code is correct or
102		- * the test code is bad.
103		-* Execute the tests on a computer using simulations of application loads when possible.
104		-* There are tools to test thread-based code like ConTest.