Changes for page Concurrency

Summary

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

Details

Page properties

Content

...	...	@@ -45,16 +45,12 @@
45	45	* Deadlock
46	46	* Livelock
47	47	* Thread Pools
	48	+ * Runnable
	49	+ * Callable
48	48	* Future
49		- * Also these??
50		- * Synchronization: General term for techniques that control the access of multiple threads to shared resources.
51		- * Race Condition: A situation where the system's behavior depends on the relative timing of events, often leading to bugs.
52		- * Semaphore: An abstract data type used to control access to a common resource by multiple threads.
53		- * Locks: Mechanisms to ensure that only one thread can access a resource at a time.
54		- * Atomic Operations: Operations that are completed in a single step relative to other threads.
55		- * Thread Safety
	51	+ * Java Executor Framework
56	56	* Producer-consumer
57		- * Reader-recorder vs Reader Writer??
	53	+ * Reader-recorder
58	58	* Philosopher problem → Study algorithms and their application in solutions.
59	59
60	60	### Watch out for dependencies between synchronized methods
...	...	@@ -87,3 +87,22 @@
87	87	* Client-based locking: User has to manually implement locking. This approach error prone and hard to maintain.
88	88	* 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.
89	89	* 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.