Changes for page Concurrency

Summary

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

Details

Page properties

Content

...	...	@@ -4,7 +4,7 @@
4	4
5	5	### Why concurrency?
6	6
7		-* Concurrency is a decoupling strategy. The what is decoupled from the when. Concurrency is important and can improve the throughput and structure of an application. On the other hand, it is hard to write clean concurrent code and it is harder to debug.
	7	+* Concurrency is a decoupling strategy. The what is decoupled from the when. Concurrency is important and can improve the throughput and structure of an application. On the other hand, it is hard to write clean concurrent code and it is harder to debug. -> own: And to test, right?
8	8	* Concurrency doesn't always improve performance behavior and but it always changes the design of the program. When working with containers, you should know exactly what you are doing.
9	9	* Concurrency demands a certain amount of management effort, which degrades performance behavior and requires additional code. Proper concurrency is complex, even for simple problems. Concurrency bugs are usually not reproducible; therefore, they are often written off as one-time occurrences (cosmic rays, glitches, etc.) rather than treated as true defects, as they should be. Concurrency requires a fundamental change in design strategy.
10	10	* Challenges: When threads access out-of-sync data, incorrect results may be returned.
...	...	@@ -45,14 +45,70 @@
45	45	* Deadlock
46	46	* Livelock
47	47	* Thread Pools
48		- * Runnable
49		- * Callable
50	50	* Future
51		- * Java Executor Framework
	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
	56	+ * Race Conditions
	57	+ * Statelessness, Statefulness
	58	+ * Functional Programming
	59	+ * Cloning Data to avoid side effects
	60	+ * Side effects
52	52	* Producer-consumer
53		- * Reader-recorder
	62	+ * Reader Writer
54	54	* Philosopher problem → Study algorithms and their application in solutions.
55	55
	65	+A few more suggestions from ChatGPT:
	66	+
	67	+ Learning about concurrency algorithms and common concurrency problems is a great way to deepen your understanding of concurrent programming. Here's a list of key algorithms and problems, along with their typical solutions:
	68	+ Concurrency Algorithms:
	69	+
	70	+ Producer-Consumer:
	71	+ Problem: How to handle scenarios where one or more threads (producers) are producing data and one or more threads (consumers) are consuming it.
	72	+ Solution: Use buffers, queues, semaphores, or condition variables to synchronize producers and consumers.
	73	+
	74	+ Readers-Writers:
	75	+ Problem: How to manage access to a shared resource where some threads (readers) only read data, and others (writers) write data.
	76	+ Solution: Implement mechanisms to ensure that multiple readers can access the resource simultaneously, but writers have exclusive access.
	77	+
	78	+ Dining Philosophers:
	79	+ Problem: A classic synchronization problem dealing with resource allocation and avoiding deadlocks.
	80	+ Solution: Strategies include resource hierarchy, arbitrator, or limiting the number of philosophers.
	81	+
	82	+ Barriers:
	83	+ Problem: Synchronizing a group of threads to wait until they have all reached a certain point in their execution.
	84	+ Solution: Use barrier constructs that block threads until all have reached the barrier.
	85	+
	86	+ Concurrency Problems and Solutions:
	87	+
	88	+ Deadlocks:
	89	+ Problem: Occurs when multiple threads or processes are waiting on each other to release resources, and none of them can proceed.
	90	+ Solution: Deadlock prevention techniques (like resource ordering), deadlock avoidance (like Banker’s algorithm), and deadlock detection and recovery.
	91	+
	92	+ Race Conditions:
	93	+ Problem: Occurs when the outcome of a program depends on the relative timing of threads or processes.
	94	+ Solution: Use mutual exclusion (mutexes), atomic operations, or transactional memory to ensure that only one thread can access the shared resource at a time.
	95	+
	96	+ Livelocks:
	97	+ Problem: Threads or processes are actively performing concurrent operations, but these operations do not progress the state of the program.
	98	+ Solution: Careful algorithm design to ensure progress and avoid situations where processes continuously yield to each other.
	99	+
	100	+ Starvation:
	101	+ Problem: A thread or process does not get the necessary resources to proceed, while others continue to be serviced.
	102	+ Solution: Implement fair locking mechanisms, priority scheduling, or resource allocation strategies that ensure all processes get a chance to proceed.
	103	+
	104	+ Priority Inversion:
	105	+ Problem: A lower-priority thread holds a resource needed by a higher-priority thread, leading to the higher-priority thread waiting unexpectedly.
	106	+ Solution: Priority inheritance protocols where the lower-priority thread temporarily inherits the higher priority.
	107	+
	108	+ Thread Interference:
	109	+ Problem: When multiple threads are accessing and modifying shared data, causing unexpected results.
	110	+ Solution: Ensure that critical sections of code that access shared resources are protected using synchronization mechanisms like locks.
	111	+
56	56	### Watch out for dependencies between synchronized methods
57	57
58	58	* Dependencies between synchronized methods in concurrent code cause subtle bugs.
...	...	@@ -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.