Revisão | 32e62097bf429b893a0fca39ab38cc6ea6425d2b (tree) |
---|---|
Hora | 2022-08-23 03:07:59 |
Autor | Albert Mietus < albert AT mietus DOT nl > |
Commiter | Albert Mietus < albert AT mietus DOT nl > |
asis
@@ -1,4 +1,13 @@ | ||
1 | -.. include:: /std/localtoc.irst | |
1 | +.. .. include:: /std/localtoc.irst | |
2 | + | |
3 | +.. sidebar:: On this page (override:4) | |
4 | + :class: localtoc | |
5 | + | |
6 | + .. contents:: | |
7 | + :depth: 4 | |
8 | + :local: | |
9 | + :backlinks: none | |
10 | + | |
2 | 11 | |
3 | 12 | .. _ConcurrentComputingConcepts: |
4 | 13 |
@@ -155,8 +164,8 @@ | ||
155 | 164 | |BR| |
156 | 165 | Notice: As the compiler will insert the (low level) Semaphores_, the risk that a developer forgets one is gone! |
157 | 166 | |
158 | -Features | |
159 | --------- | |
167 | +Aspects | |
168 | +------- | |
160 | 169 | |
161 | 170 | There are many variant on messaging, mostly combinations some fundamental aspects |
162 | 171 |
@@ -165,11 +174,11 @@ | ||
165 | 174 | (A)Synchronous |
166 | 175 | ~~~~~~~~~~~~~~ |
167 | 176 | |
168 | -Synchronous messages resembles normal function-calls. Typically a “question” is send, the call awaits the | |
177 | +**Synchronous** messages resembles normal function-calls. Typically a “question” is send, the call awaits the | |
169 | 178 | answer-messages, and that answer is returned. This can be seen as a layer on top of the more fundamental send/receive |
170 | 179 | calls. An famous example is RPC_: the Remote Procedure Call. |
171 | 180 | |
172 | -Asynchronous messages are more basic: a task send a messages (to somebody else) and continues. That message can be | |
181 | +**Asynchronous** messages are more basic: a task send a messages (to somebody else) and continues. That message can be | |
173 | 182 | “data”, an “event:, a “commands” or a “query”. Only in the latter case some responds is essental. With async messages, |
174 | 183 | there is no desire that to get the answer immediately. |
175 | 184 |
@@ -189,12 +198,12 @@ | ||
189 | 198 | This is not needed when a buffer is available. Depending on the size of the buffer, some messages can be send before |
190 | 199 | the are picked-up by the receiver. |
191 | 200 | |BR| |
192 | -Note this is always asymmetric: messages need to be send before the can be read. | |
201 | +Note: this is always asymmetric; messages need to be send before the can be read. | |
193 | 202 | |
194 | -Blocking | |
195 | -~~~~~~~~ | |
203 | +(Non-) Blocking | |
204 | +~~~~~~~~~~~~~~~ | |
196 | 205 | |
197 | -Both the writer and the reader can be blocking (or not); which is a facet of the function-call. A blocking reader it | |
206 | +Both the writer and the reader can be *blocking* (or not); which is a facet of the function-call. A blocking reader it | |
198 | 207 | will always return when a messages is available -- and will pauze until then. |
199 | 208 | |BR| |
200 | 209 | Also the write-call can be blocking: it will pauze until the message can be send -- e.g. the reader is available |
@@ -204,15 +213,12 @@ | ||
204 | 213 | Then, the developer will commonly “cycle” to poll for a profitable call; and let the task do some other/background work |
205 | 214 | as well. |
206 | 215 | |
207 | -Reliable | |
208 | - | |
209 | 216 | Uni/Bi-Directional, Broadcast |
210 | 217 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
211 | 218 | |
212 | 219 | Messages --or actually the channel that transport them-- can be *unidirectional*: from sender to receiver only; |
213 | 220 | *bidirectional*: both sides can send and receive; or *broadcasted*: one message is send to many receivers [#anycast]_. |
214 | 221 | |
215 | - | |
216 | 222 | Reliability |
217 | 223 | ~~~~~~~~~~~ |
218 | 224 |
@@ -240,12 +246,19 @@ | ||
240 | 246 | Some examples |
241 | 247 | ------------- |
242 | 248 | |
243 | -In the section below, we mention a few, everyday message-passing systems, to shed light on the theoretical features | |
249 | +In the section below, we mention a few, everyday message-passing systems, to shed light on the theoretical features. | |
244 | 250 | |
245 | 251 | Pipes |
246 | 252 | ~~~~~ |
247 | 253 | |
248 | -Unix Pipes are | |
254 | +The famous *Unix Pipes* are unidirectional, reliable, blocking, asynchronous, buffered, non-networking **data-only** | |
255 | +messages. The (“stdout”) output of one process is fed as input to (one) other process. It’s data only, in one direction | |
256 | +-- but the controll can in two directions: when the second (receiving) process can’t process the data (and the buffers | |
257 | +becoming full), the first process can be slowed down (although this a not well know feature). | |
258 | + | |
259 | +It’s also an example of a quite implicit channel: the programmer (of both programs) have nothing (to little) to do | |
260 | +extra, to make it possible. | |
261 | + | |
249 | 262 | |
250 | 263 | ------------------------ |
251 | 264 |
@@ -1,4 +1,4 @@ | ||
1 | -.. -*- rst -*- | |
1 | +.. -*-rst-*- | |
2 | 2 | included in `8.BusyCores-concepts.rst` |
3 | 3 | |
4 | 4 | .. sidebar:: |
@@ -14,6 +14,7 @@ | ||
14 | 14 | * Asynchronous_communication_ |
15 | 15 | * Asynchrony_Computer_Programming_ |
16 | 16 | * Synchronization_ |
17 | + * Blocking_ | |
17 | 18 | |
18 | 19 | and (disambiguation pages): |
19 | 20 |
@@ -29,4 +30,4 @@ | ||
29 | 30 | .. _Synchronization-Disambiguation: https://en.wikipedia.org/wiki/Synchronization_(disambiguation) |
30 | 31 | .. _Async: https://en.wikipedia.org/wiki/Asynchrony |
31 | 32 | .. _Sync: https://en.wikipedia.org/wiki/Sync |
32 | - | |
33 | +.. _Blocking: https://en.wikipedia.org/wiki/Blocking_(computing) |