Changes for page Concurrency

Summary

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

Details

Page properties

Content

...	...	@@ -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-recorder vs 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.