Revision | 540326872dd8476397043be71f24084cf8d16a3c (tree) |
---|---|
Time | 2022-07-12 23:50:29 |
Author | Albert Mietus < albert AT mietus DOT nl > |
Commiter | Albert Mietus < albert AT mietus DOT nl > |
asis
@@ -27,25 +27,20 @@ | ||
27 | 27 | |
28 | 28 | As there is many theory available and even more practical expertise, but a limited set of “common words”, let describe |
29 | 29 | some basic terms. As always, we use Wikipedia as common ground, and add links for a deep-dive. |
30 | - | |
31 | -.. include:: CCC-sidebar-concurrency.irst | |
32 | - | |
30 | +|BR| | |
31 | +Again, we use ‘task’ as the most generic term of work-to-be-executed; that can be (in) a process, (on) a thread, (by) a | |
32 | +computer, etc. | |
33 | 33 | |
34 | 34 | |
35 | -TODO | |
36 | -************************************************************ | |
37 | - | |
38 | -.. todo:: All below is draft and needs work!!!! | |
39 | - | |
40 | - | |
35 | +.. include:: CCC-sidebar-concurrency.irst | |
41 | 36 | |
42 | 37 | Concurrency |
43 | 38 | ----------- |
44 | 39 | |
45 | -Concurrency_ is the ability to “compute” multiple things at the same time. | |
40 | +Concurrency_ is the ability to “compute” multiple *tasks* at the same time. | |
46 | 41 | |BR| |
47 | 42 | Designing concurrent software isn’t that complicated but; demands another mindset the when we write software that does |
48 | -one thing afer the other. | |
43 | +one tasks afer the other. | |
49 | 44 | |
50 | 45 | A typical example is a loop: suppose we have a sequence of numbers and we like to compute the square of each one. Most |
51 | 46 | developers will loop over those numbers, get one number, calculate the square, store it in another list, and continue. |
@@ -61,7 +56,6 @@ | ||
61 | 56 | sequential execution is allowed too. |
62 | 57 | |
63 | 58 | |
64 | - | |
65 | 59 | Parallelisme |
66 | 60 | ------------ |
67 | 61 |
@@ -69,7 +63,7 @@ | ||
69 | 63 | task (of the same program) on “as many cores as possible”. When we assume a thousand cores, we need a thousand |
70 | 64 | independent tasks (at least) to gain maximal speed up. A thousand at any moment! |
71 | 65 | |BR| |
72 | -It’s not only about doing a thousand things at the same time (that is not to complicated, for a computer), but also — | |
66 | +It’s not only about doing a thousand tasks at the same time (that is not to complicated, for a computer), but also — | |
73 | 67 | probably: mostly — about finishing a thousand times faster… |
74 | 68 | |
75 | 69 | With many cores, multiple program-steps can be executed at the same time: from changing the same variable, acces the |
@@ -78,24 +72,51 @@ | ||
78 | 72 | |
79 | 73 | |
80 | 74 | Distributed |
81 | ------------ | |
75 | +~~~~~~~~~~~ | |
82 | 76 | |
83 | 77 | A special form of parallelisme is Distributed-Computing_: compute on many computers. Many experts consider this |
84 | 78 | as an independent field of expertise; still --as Multi-Core_ is basically “many computers on a chips”-- its there is an |
85 | 79 | analogy [#DistributedDiff]_, and we should use the know-how that is available, to design out “best ever language”. |
86 | 80 | |
87 | -Messages & shared-data | |
88 | ----------------------- | |
89 | - | |
90 | -Communication between two (concurrent) tasks (or processes, CPUs, computers) needs the passing of data (in one or two | |
91 | -direction). Roughly, there are two ways to do so: | |
92 | - | |
93 | -Shared-Data | |
94 | - Memory (variables) that can be written and/or read by both. As the acces is typical not acces, a bit of | |
95 | 81 | |
96 | 82 | |
97 | -Controll | |
98 | -======== | |
83 | +Communication | |
84 | +------------- | |
85 | + | |
86 | +When tasks run in various environments they have to communicate: to pass data and to controll progress. Unlike in a | |
87 | +sequential program -- where the controll is trivial, as sharing data-- this needs a bit of extra effort. | |
88 | +|BR| | |
89 | +There are two main approches: shared-data of message-passing. | |
90 | + | |
91 | +Shared Memory | |
92 | +~~~~~~~~~~~~~ | |
93 | +In this model all tasks (thread or process) have some shared/common memory; typically “variables”. As the acces is | |
94 | +asynchronous, the risk exist the data is updated “at the same time” by two or more tasks. This can lead to invalid data; | |
95 | +and so Critical-Sections_ are needed. | |
96 | + | |
97 | +This is a very basic model which assumes that there is physically memory that can be shared. In distributed systems this | |
98 | +is uncommon; but for threads it’s straightforward. As disadvantage of this model is that is hazardous: Even when a | |
99 | +single access to such a shared variable is not protected by a Critical-Section_, the whole system can break [#OOCS]_. | |
100 | + | |
101 | + | |
102 | +Messages | |
103 | +~~~~~~~~ | |
104 | +A more modern approach is Message-Passing_. One task send a message (sometimes called “event”) to another task; as there | |
105 | +is a distinct sender and receiver -- and apparently no common/shared memory-- no Critical-Sections [#MPCS]_ are | |
106 | +needed. At least no explicitly. Messages can be used by all kind of task; even in a distributed system -- then the | |
107 | +message (and it data) is serialised, transmitted over a network and deserialised. Which can introduce some overhead and | |
108 | +delay. | |
109 | +|BR| | |
110 | +Many people use this networking mental model when they thing about Message-Passing_, and *wrongly* assume there is | |
111 | +always overhead. When (carefully) implemented this is not needed; and can be as efficiently as shared-memory (assuming | |
112 | +there is shared-memory to can be used). | |
113 | + | |
114 | + | |
115 | +************************************************************ | |
116 | + | |
117 | +.. todo:: All below is draft and needs work!!!! | |
118 | + | |
119 | + | |
99 | 120 | |
100 | 121 | Models |
101 | 122 | ====== |
@@ -105,6 +126,9 @@ | ||
105 | 126 | |
106 | 127 | Actors |
107 | 128 | |
129 | +Actor-Model_ | |
130 | +Actor-Model-Theory_ | |
131 | + | |
108 | 132 | A very introduce |
109 | 133 | |
110 | 134 | -------- |
@@ -127,15 +151,27 @@ | ||
127 | 151 | |BR| |
128 | 152 | But that condition does apply to Multi-Core_ too. Although the (timing) numbers do differ. |
129 | 153 | |
154 | +.. [#OOCS] | |
155 | + The brittleness of Critical-Sections_ can be reduced by embedding (the) (shared-) variable in an OO abstraction. By | |
156 | + using *getters and *setters*, that controll the access, the biggest risk is (mostly) gone. That does not, however, | |
157 | + prevent deadlocks_ nor livelocks_. Also see the note below. | |
158 | + | |
159 | +.. [#MPCS] | |
160 | + This is not completely correct; Message-Passing_ can be implemented on top of shared-memory. Then, the implementation | |
161 | + of this (usually) OO-abstraction contains the Critical-Sections_; a bit as described in the footnote above. | |
162 | + | |
163 | + | |
164 | + | |
130 | 165 | .. _pthreads: https://en.wikipedia.org/wiki/Pthreads |
131 | 166 | .. _Threads: https://en.wikipedia.org/wiki/Thread_(computing) |
132 | 167 | .. _Multi-Core: https://en.wikipedia.org/wiki/Multi-core_processor |
133 | 168 | |
134 | 169 | .. _deadlocks: https://en.wikipedia.org/wiki/Deadlock |
135 | 170 | .. _livelocks: https://en.wikipedia.org/wiki/Deadlock#Livelock |
136 | -.. _Critical-Sections: https://en.wikipedia.org/wiki/Critical_section | |
171 | +.. _Critical-Section: https://en.wikipedia.org/wiki/Critical_section | |
172 | +.. _Critical-Sections: Critical-Section_ | |
137 | 173 | .. _Distributed-Computing: https://en.wikipedia.org/wiki/Distributed_computing |
138 | - | |
174 | +.. _Message-Passing: https://en.wikipedia.org/wiki/Message_passing | |
139 | 175 | .. _Actor-Model: https://en.wikipedia.org/wiki/Actor_model |
140 | 176 | .. _Actor-Model-Theory: https://en.wikipedia.org/wiki/Actor_model_theory |
141 | 177 |
@@ -52,7 +52,7 @@ | ||
52 | 52 | |
53 | 53 | wc: |
54 | 54 | @echo "lines words file" |
55 | - @wc -lw `find CCastle/ -iname \*rst`|sort -r | |
55 | + @wc -lw `find CCastle/ -iname \*rst`|sort -r | grep -v /index.rst | grep -v /zz.todo.rst | |
56 | 56 | |
57 | 57 | sidebar: |
58 | 58 | @grep "include::" `find CCastle/ -type f -name \*.rst` /dev/null | grep sidebar| sort| sed 's/:../:\t\t ../' |