Changes for page Concurrency

Summary

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

Details

Page properties

Content

...	...	@@ -1,69 +1,45 @@
1		-## Concurrency
	1	+Objects are abstractions of processing, **threads are abstractions of timing**.
2	2
3		-* Objects are abstractions of processing, threads are abstractions of timing.
	3	+### Why Concurrency?
4	4
5		-### Why concurrency?
	5	+* **Concurrency is a decoupling strategy**. The what is decoupled from the when.
	6	+* **Concurrency is can improve the throughput and structure** of an application.
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. -> own: And to test, right?
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		-* 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		-* Challenges: When threads access out-of-sync data, incorrect results may be returned.
	8	+### Why Not Concurrency?
11	11
12		-### Principles of defensive concurrency programming
	10	+* **Unclean**: It is hard to write clean concurrent code, and it is harder to test and debug.
	11	+* **Design Changes**: Concurrency doesn't always improve performance behavior and but it always requires fundamental design changes.
	12	+* **Extra Management**: Concurrency demands a certain amount of management effort, which degrades performance behavior and requires additional code.
	13	+* **Complexity**: Proper concurrency is complex, even for simple problems.
	14	+* **Unreproducible**: 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.
	15	+* **Side-Effects**: When threads access out-of-sync data, incorrect results may be returned.
13	13
14		-* SRP
15		- * Changes to concurrent code should not be mixed with changes to the rest of the code. So you should separate the two cleanly.
16		- * Concurrency has its own life cycle with development, modification, and polish.
17		- * Concurrent code is associated with special problems that have a different form and often a higher degree of difficulty than non-concurrent code.
18		-* Constrain the range of validity of data
19		- * Take data encapsulation to heart; restrict access to all shared resources.
20		- * 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.
21		-* Work with copies of the data
22		- * One can sometimes get around data sharing by:
23		- * working with copies of objects and treating them as read-only objects.
24		- * making multiple copies of an object, having multiple threads compute results on it, and merging those results into a single thread.
25		- * It is often worth creating multiple objects to avoid concurrency issues.
26		-* Threads should be as independent of each other as possible.
27		- * Threads should not share data or know anything about each other. Instead, they should prefer to work with their own local variables.
28		- * Try to decompose data into independent subsets that can be processed by independent threads, possibly in different processes.
	17	+### Defensive Concurrency Programming
29	29
30		-### Things to learn before working with concurrency
	19	+* **Single-Responsibility Principle**
	20	+ * **Separation of code**: Changes to concurrent code should not be mixed with changes to the rest of the code. So you should separate the two cleanly.
	21	+ * **Separation of change**: Concurrent code has special problems that are different, and often more serious, than sequential code. This means that concurrent and sequential code should be changed separately, not within the same commit, or even within the same branch.
	22	+* **Principle of Least Privilege**: Limit concurrent code to the resources it actually needs to avoid side effects. Minimize the amount of shared resources. Divide code blocks and resources into smaller blocks to apply more granular, and therefore more restrictive, resource access.
	23	+* **Data Copies**: You can sometimes avoid shared resources by either working with copies of data and treating them as read-only, or by making multiple copies of the data, having multiple threads compute results on them, and merging those results into a single thread. It is often worth creating multiple objects to avoid concurrency problems.
	24	+* **Independence**: Threads should be as independent as possible. Threads should not share their data or know anything about each other. Instead, they should prefer to work with their own local variables. Try to break data into independent subsets that can be processed by independent threads, possibly in different processes.
31	31
32		-* Get to know your library
33		- * Use the thread-safe collections provided.
34		- * Use the executor framework to execute disjointed tasks.
35		- * Use non-blocking solutions if possible.
36		- * Multiple library classes are not thread-safe.
37		-* Thread-safe collections
38		- * So you should use ConcurrentHashMap instead of HashMap.
39		- * Author's recommendations: java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks.
40		-* Get to know execution models
41		- * Basic definitions
42		- * Bound Resources
43		- * Mutual Exclusion
44		- * Starvation
45		- * Deadlock
46		- * Livelock
47		- * Thread Pools
48		- * Runnable
49		- * Callable
50		- * Future
51		- * Java Executor Framework
52		- * Producer-consumer
53		- * Reader-recorder
54		- * Philosopher problem → Study algorithms and their application in solutions.
	26	+### Basic Knowledge
55	55
	28	+Before starting to write concurrent code, get familiar with the following basics:
	29	+
	30	+* **Libraries**: Use the thread-safe collections provided. Use non-blocking solutions if possible. Be aware multiple library classes are not thread safe.
	31	+* **Concepts**: Mutual Exclusion, Deadlock, Livelock, Thread Pools, Semaphore, Locks, Race Condition, Starvation,
	32	+* **Patterns**: Producer-consumer, Reader-Writer
	33	+* **Algorithms**: Study common algorithms and their use in solutions. For example, the Dining Philosophers problem.
	34	+
56	56	### Watch out for dependencies between synchronized methods
57	57
58		-* Dependencies between synchronized methods in concurrent code cause subtle bugs.
59		-* Avoid applying more than one method to a shared object. If this is not possible, you have three options:
60		- * 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.
61		- * 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.
62		- * 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.
63		-* Keep synchronized sections small.
64		- * Locks are expensive because they add administrative overhead to delays. On the other hand, critical sections must be protected.
65		- * Critical sections, are parts of the code that are only executed correctly if several threads do not access it at the same time.
66		- * Keep synchronized sections as small as possible.
	37	+* **Avoid dependencies between synchronized methods**: Synchronized means that only one thread can access a method at a time. In concurrent code, such dependencies, such as when one synchronized method calls another, can cause subtle bugs like deadlocks and performance issues.
	38	+* **Avoid applying more than one method to a shared object.** If this is not possible, you have three options:
	39	+ * **Client-based locking**: The client locks the server, calls all the server methods, and then releases the lock.
	40	+ * **Server-based locking**: Create a method in the server that locks the server, calls all the methods, and then unlocks the server. A client can now safely call this new method.
	41	+ * **Adapted Server**: Create an intermediate component to perform the lock. This is a variant of server-based locking when the original server cannot be changed.
	42	+* **Keep synchronized sections small. **Locks are expensive because they add administrative overhead and delay. On the other hand, critical sections need to be protected. Critical sections are pieces of code that will only run correctly if they are not accessed by multiple threads at the same time. Keeping synchronized sections small avoids both problems.
67	67
68	68	### Writing correct shutdown code is difficult
69	69
...	...	@@ -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.