Changes for page Concurrency

Last modified by chrisby on 2024/06/02 15:15

From 1.1 to 1.2 From 1.8 to 1.9

From version 1.2

edited by chrisby
on 2023/11/26 19:12

Change comment: There is no comment for this version

To version 1.8

edited by chrisby
on 2023/11/26 20:59

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -1,76 +1,88 @@
--* When I/O is the bottleneck of your application, more threads will increase the performance in opposite to when CPU is the bottleneck.
--* Stress Testing: Checking the throughput of an application by sending a huge amount of requests and examining the response times.
--* Isolate concurrent code by putting it in a few separate classes.
--* Always consider the concept of execution paths: The amount of possible interleaving of instructions that are processed by at least two threads. For example, objects with mutable states could unintentionally cause different results doing the same operation twice.
--* Atomic operation = operation which can not be interrupted by other threads. But for unsynchronized processes threads can put instructions between two atomic operations.
--* `synchronized` prevents unintended side-effects.
--* Server-based locking is preferred over client-based locking.
--    * Server-based locking: The class used takes care of internal locking, so the user has nothing else to worry about.
--    * Client-based locking: User has to manually implement locking. This approach error prone and hard to maintain.
--* 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.
--* As little synchronized code (`synchronized`) as possible should be used. And if, then only for small, critical code sections.
++## Concurrency
--### Prevent Deadlocks
++* Objects are abstractions of processing, threads are abstractions of timing.
--* Do this by making one of its four conditions impossible.
++### Why concurrency?
--### Mutual Exclusion (Mutex)
++* 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?
++* 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.
++* 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.
++* Challenges: When threads access out-of-sync data, incorrect results may be returned.
--* Description:
--    * When resources can't be used by mutual thread and
--    * there are less resources than threads.
--* Solutions:
--    * Use concurrently accessible resources like AtomicInteger.
--    * Increase the number of resources until its greater or equal to the number of competing threads.
--    * Check if every required resource is accessible before the task starts.
++### Principles of defensive concurrency programming
--### Lock & Wait
++* SRP
++    * Changes to concurrent code should not be mixed with changes to the rest of the code. So you should separate the two cleanly.
++    * Concurrency has its own life cycle with development, modification, and polish.
++    * Concurrent code is associated with special problems that have a different form and often a higher degree of difficulty than non-concurrent code.
++* Constrain the range of validity of data
++    * Take data encapsulation to heart; restrict access to all shared resources.
++    * So you should keep the mass of shared code low, and shared resources should only be claimed by threads that need them. That means one should divide the blocks and resources into smaller blocks if necessary.
++* Work with copies of the data
++    * One can sometimes get around data sharing by:
++        * working with copies of objects and treating them as read-only objects.
++        * making multiple copies of an object, having multiple threads compute results on it, and merging those results into a single thread.
++    * It is often worth creating multiple objects to avoid concurrency issues.
++* Threads should be as independent of each other as possible.
++    * Threads should not share data or know anything about each other. Instead, they should prefer to work with their own local variables.
++    * Try to decompose data into independent subsets that can be processed by independent threads, possibly in different processes.
--* Description:
--    * 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.
--* Solutions:
--    * Before reservation of a resource, check its accessibility.
--    * If a resource is not accessible, release every resource and start from anew.
--* Dangers:
--    * Starvation: A thread never achieves to reserve all required resources.
--    * Livelock: Thread gets tangled up.→ This approach is always applicable but inefficient as it causes a bad performance.
++### Things to learn before working with concurrency
--### No preemption
++* Get to know your library
++    * Use the thread-safe collections provided.
++    * Use the executor framework to execute disjointed tasks.
++    * Use non-blocking solutions if possible.
++    * Multiple library classes are not thread-safe.
++* Thread-safe collections
++    * So you should use ConcurrentHashMap instead of HashMap.
++    * Author's recommendations: java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks.
++* Get to know execution models
++    * Basic definitions
++        * Bound Resources
++        * Mutual Exclusion
++        * Starvation
++        * Deadlock
++        * Livelock
++        * Thread Pools
++        * Future
++        * Synchronization: General term for techniques that control the access of multiple threads to shared resources.
++        * Race Condition: A situation where the system's behavior depends on the relative timing of events, often leading to bugs.
++        * Semaphore: An abstract data type used to control access to a common resource by multiple threads.
++        * Locks: Mechanisms to ensure that only one thread can access a resource at a time.
++        * Atomic Operations: Operations that are completed in a single step relative to other threads.
++        * Thread Safety
++    * Producer-consumer
++    * Reader-recorder vs Reader Writer??
++    * Philosopher problem → Study algorithms and their application in solutions.
--* Description:
--    * A thread is unable to steal a resources reserved by another thread.
--* Solution:
--    * 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.
++### Watch out for dependencies between synchronized methods
--### Circular Waiting  /  Deadly Embrace
++* Dependencies between synchronized methods in concurrent code cause subtle bugs.
++* Avoid applying more than one method to a shared object. If this is not possible, you have three options:
++    * Client-based locking: the client should lock the server before the first method is called and ensure that the lock includes the code that calls the last method.
++    * Server-based locking: Create a method in the server that locks the server, calls all methods, and then unlocks the server. Have the client call the new method.
++    * Adapted Server: Create an intermediate component that performs the lock. This is a variant of server-based locking if the original server cannot be changed.
++* Keep synchronized sections small.
++    * Locks are expensive because they add administrative overhead to delays. On the other hand, critical sections must be protected.
++    * Critical sections, are parts of the code that are only executed correctly if several threads do not access it at the same time.
++    * Keep synchronized sections as small as possible.
--* Description:
--    * When two or more threads require a resource which is already reserved by another of these threads.
--    * Example:
--        * Thread T1 has resource R1 and waits for R2 to be released.
--        * Thread T2 has resource R2 and waits for R1 to be released.
--* Solution:
--    * All threads reserve all resources in a the same order.
--* Problems:
--    * 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.
--    * Unnecessarily long locked resources.
--    * Order can not always be specified.
++### Writing correct shutdown code is difficult
--### Problems of testing multi-threaded methods
++* You should think about a shutdown as early as possible and get it running as soon as possible. If you wait, it will always take longer. Study the available algorithms because this task is probably harder than you think.
++    * TODO: Why do I need shutdown code?
--* Very tricky which is why concurrency should be avoided in the first place.
--* In general this requires a lot of iteration which makes it resource intensive.
--* The outcome is architecture dependent (OS, hardware) which introduced randomness and make the error detection unreliable.
++Some Notes:
--### Solution approaches for testing multi-threaded methods
--
--* Monte-Carlo-Tests
--    * Write flexible, adaptive tests.
--    * Repeatedly run them on a test server and randomly vary the test settings.
--    * If something fails, the code is defect and the applied settings should be logged.
--    * Do this early to gain tests ASAP for your testing repertoire or CI-server.
--* Execute these tests on every platform over a long time to increase the probability that
--    * the production code is correct or
--    * the test code is bad.
--* Execute the tests on a computer using simulations of application loads when possible.
--* There are tools to test thread-based code like ConTest.
++* When I/O is the bottleneck of your application, more threads will increase the performance in opposite to when CPU is the bottleneck.
++* Stress Testing: Checking the throughput of an application by sending a huge amount of requests and examining the response times.
++* Isolate concurrent code by putting it in a few separate classes.
++* Always consider the concept of execution paths: The amount of possible interleaving of instructions that are processed by at least two threads. For example, objects with mutable states could unintentionally cause different results doing the same operation twice.
++* Atomic operation = operation which can not be interrupted by other threads. But for unsynchronized processes threads can put instructions between two atomic operations.
++* `synchronized` prevents unintended side-effects.
++* Server-based locking is preferred over client-based locking.
++    * Server-based locking: The class used takes care of internal locking, so the user has nothing else to worry about.
++    * Client-based locking: User has to manually implement locking. This approach error prone and hard to maintain.
++* 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.
++* As little synchronized code (`synchronized`) as possible should be used. And if, then only for small, critical code sections.