Different Concurrency Paradigms and Constructs for Distributed Systems Dr Vladimir Z. Tosic 1 Term 2 2020
MAIN TOPICS IN THE LAST LECTURE… (MAINLY IN BEN-ARI CHAPTER 10) • Some “ Big ig Ideas ” about concurrency in distributed systems (and wider) • Ben- Ari’s distributed ributed system stem model (remember these assumptions!) • Ric Ricart-Ag Agra rawala wala algo lgorit ithm hm for dist istrib ributed uted mutu tual al exclusion n – DM DME (distributed critical sections) • Token-pa passi ssing algo lgorit ithms hms for distributed mutual exclusion – another Ricart-Agrawala algorithm 2
MAIN TOPICS IN THIS LECTURE… ( NOT IN THE BEN-ARI TEXTBOOK! ) • Ricart-Agrawala algorithm demo in DA in DAJ • Revision of message-passing using CSP channels • The actor or model for message-passing concurrency • Brief overview of some other dist istrib ribute uted d messag age- passing ing and dist istrib ribute uted d shared d memory ory paradigm igms • Notes on some other concepts for programming asynchron chronou ous s dist istrib ribute uted d syste stems ms 3
REVISION AND DAJ DEMO OF RICART-AGRAWALA ALGORITHMS From Chapter 10 and Appendix D.3 in Ben- Ari’s Textbook and DAJ docu cumentat entation ion 4
RICART-AGRAWALA ALGORITHM FOR DME – MAIN IDEAS (REVISION) • Using tick icket et numbers ers , similarly to Lamport’s bakery algorithm • Nodes choose ticket numbers and compare them • In a distributed system these numbers cannot be compared directly, so they have to be sent t in in messag sages es • Node with low lowest t number er can enter CS (critical section) • Other nodes have to wait until CS is free again • Vir irtua ual l queue does not exist as a data structure, but it is the effect of messages – nodes ordered as if in a queue 5
RICART-AGRAWALA ALGORITHM – COMPLETE (1/3) 6
RICART-AGRAWALA ALGORITHM – COMPLETE (2/3) 7
RICART-AGRAWALA ALGORITHM – COMPLETE (3/3) 8
Read about DAJ: https://github.com/motib/daj (URL), Appendix D.3 in textbook RICART-AGRAWALA ALGORITHM DEMO IN BEN- ARI’S DAJ TOOL Task for you: Experiment with DAJ 9
TOKEN-PASSING ALGORITHMS FOR DME – MAIN IDEAS (REVISION) • Token is permission to enter CS – only 1 node has token at any 1 time so mutua tual l exclus lusion ion holds • Effic ficiencies iencies : token not passed unless necessary (contin tinge gency ncy), only 1 message needed to transfer token between nodes, node with token can enter CS multiple times without token transfer • Ch Chall llenges: ensuring freedom from deadlock and starvation • In Ricart-Agrawala token passing algorithm, token includes array grante nted with ticket number of each node the las last tim ime it had permission to CS – enables determining what outstanding request st messages have not yet been satisfied 10
REVISION OF SYNCHRONOUS VS. ASYNCHRONOUS COMMUNICATION From Chapter 8 in Ben- Ari’s Text xtboo book 11
SOME IMPACTS OF THE DISTRIBUTED COMPUTING CONTEXT (REVISION) • In compl plex, x, decent ntrali ralised system stems (e.g. on the Internet) • message passing has advantages over shared memory • asynchronous communication has advantages over synchronous communication • immutable data has advantages over mutable data • … • Flex lexibil ibilit ity is needed because in distributed systems change is frequent and often unpredictable • caused by technology or by business aspects 12
SYNCHRONOUS VS. ASYNCHRONOUS COMMUNICATION (REVISION) • Synchron hronou ous – communication cannot happen until both parties are ready at the same tim ime, e.g. telephone call • Asynchr chron onou ous – parties need not be ready at the same time, e.g. email; requires storing data elements • Shared memory – asynchronous • Message passing – synchronous or asynchronous 13
SYNCHRONOUS COMMUNICATION USING MESSAGES (REVISION) • Exchange of a message is an atomic mic action tion requiring participation of both the sender and the recei eiver er • If sender is ready, but receiver is not – sender r is is b bloc locked • If sender is not ready, but receiver is – receiv iver er is is b bloc locked • Exchange of a message synchro chroni nises the execution sequences of these 2 processes • Can be 1-wa way y or 2-way y communication 14
ASYNCHRONOUS COMMUNICATION USING MESSAGES (REVISION) • No No tempora poral l depende dence nce (other then ordering) between the execution sequences of these 2 processes, but must st be 1-wa way • Sender can send a message and contin tinue wit without ut bloc locking ing • The message is stored in a buff ffer er – a (finite size > 0) queue queue of data elements in the communication channel • Issues: writing into a full buffer, reading from an empty buffer • Receiver can later check the buffer for new messages 15
THE NEED FOR ASYNCHRONOUS COMMUNICATION • In distributed/decentralised systems (e.g. Internet), flexibility offered by asynchron chronou ous communication is often advantageous • E.g. due to considerable communication delays, failures of communication links or distributed computers, … • But this can lead to more e dif ifficult icult program rammin ming 16
LANGUAGE SUPPORT FOR ASYNCHRONOUS COMMUNICATION • Modern programming languages have various advance ced d constr structs ucts for asynchronous communication (and other concurrency) • Simple additions: callback function, promise/future mise/future , async/await /await , … • Bigger paradigm shifts: CS CSP channe nels ls , acto tor r model , (tuple) spaces, … • Not only purpose-built concurrent languages, but also extensions of popular general programming languages • We will give a brief overview of some paradigms and constructs, but details remain for your independent research 17
SOME MESSAGE PASSING CONCURRENCY PARADIGMS From Chapter 8 in Ben- Ari’s Text xtboo book 18
ADDRESSING IN MESSAGE PASSING • Symmetric metric addressing essing: sender and receiver know each other’s address • Channels ls: instead of addresses, 2 or more processes use shared named d channels • Asymmetric etric addressin essing: a client knows address of a server, but the server need not know address the client • No addressin ssing: receiver is determined based on matching on the message structure 19
RENDEZVOUS – OVERVIEW • Type of synchronous (blocking) communication • Can be appropriate for some servers (but asynchronous is often better) • Supported in Ada and some other programming languages • Ca Call lling ing proce cess ss must know identity of accept pting ing process ess and entry ry point (in the accepting process) • Accepting proc. need not know identity of calling proc. • Optional parameters and return values • Limitations: tigh ight t coupli ling, active participation of both processes 20
RENDEZVOUS – EXAMPLE 21
RENDEZVOUS SEMANTICS – 2 TIME DIAGRAMS a) b) 22
REMOTE PROCEDURE CALL (RPC) • Another type of synchronous (blocking) communication • Supported (differently) in many prog. languages and distributed system frameworks: Java RMI, CORBA, some Web service frameworks, … • Client calls server in the way identical to local procedure call • Different ways to locate servers, e.g. registry • New process is created (locally or remotely) to handle this call, but this is transparent to the client • Easier programming, somewhat less tight coupling than rendezvous • More widely used (but asynchronous is still better) 23
REMOTE PROCEDURE CALL (RPC) – COMPONENTS 24
CSP (COMMUNICATING SEQUENTIAL PROCESSES) CHANNELS (REVISION) • Connecting senders and receivers • Typed: type of messages must be declared and matched • Can be synchro chrono nous us or asynchron chronou ous • Originally synchronous, then extended to asynchronous • Sending value of variable x on channel ch : 𝑑ℎ ⇐ 𝑦 (pseudocode), 𝑑ℎ ! 𝑦 (Promela) • Receiving value from channel ch and storing it in variable y : 𝑑ℎ ⇒ 𝑧 (pseudocode), 𝑑ℎ ? 𝑧 (Promela) • Effic ficient ient and easy to use communication mechanism 25
CSP CHANNELS – LIMITATIONS • Channels lack flexibility – programs using channels must be configured (at compile-time or initialisation-time) • Not a dynamic, run-time change of configuration • E.g. difficult to program (without workarounds) a realistic, flexible server using channels because it could offer only specific channels for access • Deadloc lock or starvation arvation possible, if not programmed carefully 26
THE ACTOR MODEL From online resources 27
This is a cropped version of the CC BY 2.0 image from: https://www.flickr.com/photos/35332562@N04/3363633021 ??? 28
THE ACTOR MODEL – INTRODUCTORY VIDEOS • Task for you: Watch these 2 videos (in the given order) • Finematics, “Actor Model Explained” [video, 4:32], YouTube, 17 Apr. 2018, at: https://www.youtube.com/watch?v=ELwEdb_pD0k • See also: https://finematics.com/actor-model-explained/ • Mark Lewis, “The Actor Model” [video, 4:29], YouTube, 13 Feb. 2016, at: https://www.youtube.com/watch?v=un- pSOlTaY0 29
Recommend
More recommend
