提交: 540326872dd8476397043be71f24084cf8d16a3c - DocIdeas (hg)

Commit MetaInfo

• 修订版: 540326872dd8476397043be71f24084cf8d16a3c (tree)
• 时间: 2022-07-12 23:50:29
• 作者: Albert Mietus < albert AT mietus DOT nl >
• Commiter: Albert Mietus < albert AT mietus DOT nl >

Log Message

asis

更改概述

• modified: CCastle/2.Analyse/8.ConcurrentComputingConcepts.rst
• modified: Makefile

差异

diff -r d27b4b065457 -r 540326872dd8 CCastle/2.Analyse/8.ConcurrentComputingConcepts.rst
--- a/CCastle/2.Analyse/8.ConcurrentComputingConcepts.rst	Tue Jul 12 13:20:19 2022 +0200
+++ b/CCastle/2.Analyse/8.ConcurrentComputingConcepts.rst	Tue Jul 12 16:50:29 2022 +0200
@@ -27,25 +27,20 @@
 
 As there is many theory available and even more practical expertise, but a limited set of “common words”, let describe
 some basic terms. As always, we use Wikipedia as common ground, and add links for a deep-dive.
-
-.. include:: CCC-sidebar-concurrency.irst
-
+|BR|
+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
+computer, etc.
 
 
-TODO
-************************************************************
-
-.. todo:: All below is draft and needs work!!!!
-
-
+.. include:: CCC-sidebar-concurrency.irst
 
 Concurrency
 -----------
 
-Concurrency_ is the ability to “compute” multiple things at the same time.
+Concurrency_ is the ability to “compute” multiple *tasks* at the same time.
 |BR|
 Designing concurrent software isn’t that complicated but; demands another mindset the when we write software that does
-one thing afer the other.
+one tasks afer the other.
 
 A typical example is a loop: suppose we have a sequence of numbers and we like to compute the square of each one. Most
 developers will loop over those numbers, get one number, calculate the square, store it in another list, and continue.
@@ -61,7 +56,6 @@
 sequential execution is allowed too.
 
 
-
 Parallelisme
 ------------
 
@@ -69,7 +63,7 @@
 task (of the same program) on “as many cores as possible”.  When we assume a thousand cores, we need a thousand
 independent tasks (at least) to gain maximal speed up. A thousand at any moment!
 |BR|
-It’s not only about doing a thousand things at the same time (that is not to complicated, for a computer), but also —
+It’s not only about doing a thousand tasks at the same time (that is not to complicated, for a computer), but also —
 probably: mostly — about finishing a thousand times faster…
 
 With many cores, multiple program-steps can be executed at the same time: from changing the same variable,  acces the
@@ -78,24 +72,51 @@
 
 
 Distributed
------------
+~~~~~~~~~~~
 
 A special form of parallelisme is Distributed-Computing_: compute on many computers. Many experts consider this
 as an independent field of expertise; still --as Multi-Core_ is basically “many computers on a chips”-- its there is an
 analogy [#DistributedDiff]_, and we should use the know-how that is available, to design out “best ever language”.
 
-Messages & shared-data
-----------------------
-
-Communication between two (concurrent) tasks (or processes, CPUs, computers) needs the passing of data (in one or two
-direction). Roughly, there are two ways to do so:
-
-Shared-Data
-   Memory (variables) that can be written and/or read by both. As the acces is typical not acces, a bit of 
 
 
-Controll
-========
+Communication
+-------------
+
+When tasks run in various environments they have to communicate: to pass data and to controll progress. Unlike in a
+sequential program -- where the controll is trivial, as sharing data-- this needs a bit of extra effort.
+|BR|
+There are two main approches: shared-data of message-passing.
+
+Shared Memory
+~~~~~~~~~~~~~
+In this model all tasks (thread or process) have some shared/common memory; typically “variables”. As the acces is
+asynchronous, the risk exist the data is updated “at the same time” by two or more tasks. This can lead to invalid data;
+and so Critical-Sections_ are needed.
+
+This is a very basic model which assumes that there is physically memory that can be shared. In distributed systems this
+is uncommon; but for threads it’s straightforward. As disadvantage of this model is that is hazardous: Even when a
+single access to such a shared variable is not protected by a Critical-Section_, the whole system can break [#OOCS]_.
+
+
+Messages
+~~~~~~~~
+A more modern approach is Message-Passing_. One task send a message (sometimes called “event”) to another task; as there
+is a distinct sender and receiver -- and apparently no common/shared memory-- no Critical-Sections [#MPCS]_ are
+needed. At least no explicitly. Messages can be used by all kind of task; even in a distributed system -- then the
+message (and it data) is serialised, transmitted over a network and deserialised. Which can introduce some overhead and
+delay.
+|BR|
+Many people use this networking mental model when they thing about Message-Passing_, and *wrongly* assume there is
+always overhead. When (carefully) implemented this is not needed; and can be as efficiently as shared-memory (assuming
+there is shared-memory to can be used).
+
+
+************************************************************
+
+.. todo:: All below is draft and needs work!!!!
+
+
 
 Models
 ======
@@ -105,6 +126,9 @@
 
 Actors
 
+Actor-Model_
+Actor-Model-Theory_
+
 A very introduce
 
 --------
@@ -127,15 +151,27 @@
    |BR|
    But that condition does apply to Multi-Core_ too. Although the (timing) numbers do differ.
 
+.. [#OOCS]
+   The brittleness of Critical-Sections_ can be reduced by embedding (the) (shared-) variable in an OO abstraction. By
+   using *getters and *setters*, that controll the access, the biggest risk is (mostly) gone. That does not, however,
+   prevent deadlocks_ nor livelocks_. Also see the note below.
+
+.. [#MPCS]
+   This is not completely correct; Message-Passing_ can be implemented on top of shared-memory. Then, the implementation
+   of this (usually) OO-abstraction contains the Critical-Sections_; a bit as described in the footnote above.
+
+
+
 .. _pthreads: 			https://en.wikipedia.org/wiki/Pthreads
 .. _Threads:			https://en.wikipedia.org/wiki/Thread_(computing)
 .. _Multi-Core:			https://en.wikipedia.org/wiki/Multi-core_processor
 
 .. _deadlocks:			https://en.wikipedia.org/wiki/Deadlock
 .. _livelocks:			https://en.wikipedia.org/wiki/Deadlock#Livelock
-.. _Critical-Sections:		https://en.wikipedia.org/wiki/Critical_section
+.. _Critical-Section:		https://en.wikipedia.org/wiki/Critical_section
+.. _Critical-Sections:		Critical-Section_
 .. _Distributed-Computing:	https://en.wikipedia.org/wiki/Distributed_computing
-
+.. _Message-Passing:		https://en.wikipedia.org/wiki/Message_passing
 .. _Actor-Model:		https://en.wikipedia.org/wiki/Actor_model
 .. _Actor-Model-Theory:		https://en.wikipedia.org/wiki/Actor_model_theory
 

diff -r d27b4b065457 -r 540326872dd8 Makefile
--- a/Makefile	Tue Jul 12 13:20:19 2022 +0200
+++ b/Makefile	Tue Jul 12 16:50:29 2022 +0200
@@ -52,7 +52,7 @@
 
 wc:
 	@echo "lines	words	file"
-	@wc -lw `find CCastle/ -iname \*rst`|sort -r
+	@wc -lw `find CCastle/ -iname \*rst`|sort -r | grep -v /index.rst | grep -v /zz.todo.rst
 
 sidebar:
 	@grep "include::" `find CCastle/ -type f -name \*.rst` /dev/null | grep sidebar| sort| sed 's/:../:\t\t ../'