Συνέπεια μνήμης σε πολυπύρηνα/πολυεπεξεργαστικά συστήματα ΙΙΙ 1 lalis@inf.uth.gr
Απλοποιημένο μοντέλο συστήματος CPU/cores πάνω σε δίαυλο/δίκτυο (bus/interconnect) για απλότητα, εδώ CPU = core Η κυρίως μνήμη είναι ξεχωριστή από τις CPU Η ταχύτητα πρόσβασης της μνήμης είναι αργή, σε σχέση με την ταχύτητα εκτέλεσης της CPU Αν η CPU προσπελάζει την μνήμη πολύ συχνά, επιβραδύνεται σημαντικά η εκτέλεση του κώδικα Στόχος Α: μείωση της αλληλεπίδρασης με την μνήμη Στόχος Β: επικάλυψη της επικοινωνίας με εκτέλεση ΙΙΙ 2 lalis@inf.uth.gr
CPU CPU CPU memory system cache cache cache main memory bus fast slow very slow external memory ΙΙΙ 3 lalis@inf.uth.gr
Μοντέλο προσπέλασης μνήμης Η μνήμη ως «ανεξάρτητο» υποσύστημα Προσφέρει «υπηρεσίες» αποθήκευσης Η αλληλεπίδραση γίνεται μέσα από τις λειτουργίες πρόσβασης για διάβασμα/γράψιμο της μνήμης Φόρτωμα/Διάβασμα (load): αίτηση προς την μνήμη, και απάντηση (με την τιμή) από την μνήμη Αποθήκευση/Γράψιμο (store): αίτηση της CPU προς την μνήμη θεωρούμε ότι δεν αποτυγχάνει Οι λειτουργίες θεωρούνται ατομικές ΙΙΙ 4 lalis@inf.uth.gr
Βασικά προβλήματα Memory consistency Η σειρά με την οποία αλλάζουν τα περιεχόμενα της μνήμης δεν είναι δεδομένη / προφανής Σημασία έχει και η σειρά με την οποία μεταδίδονται αλλαγές που γίνονται σε διαφορετικές μεταβλητές Cache coherence Η συνέπεια των «αντιγράφων» των δεδομένων που βρίσκονται στο σύστημα της μνήμης της δεν είναι δεδομένη / προφανής Σημασία έχει το αν και πως μεταδίδονται οι αλλαγές που γίνονται σε μεμονωμένες μεταβλητές ΙΙΙ 5 lalis@inf.uth.gr
Memory consistency P1 cache memory cache P2 store load order? ΙΙΙ 6 lalis@inf.uth.gr
Memory consistency model Το μοντέλο (συνέπειας) μνήμης CΜ προδιαγράφει τις επιτρεπτές συμπεριφορές μιας ταυτόχρονης εκτέλεσης με κοινή μνήμη ανάμεσα στα νήματα Συνεπείς εκτελέσεις: συμβατές με το CΜ Μη συνεπείς εκτελέσεις: ασύμβατες με το CΜ Μια υλοποίηση (σύστημα) είναι συνεπής (ως προς CΜ) αν επιτρέπει μόνο συνεπείς εκτελέσεις Γενικά, για κάθε ταυτόχρονη εκτέλεση, υπάρχουν πολλές διαφορετικές συνεπείς εκτελέσεις ΙΙΙ 7 lalis@inf.uth.gr
Program Order & Memory Order Program order (σειρά στο πρόγραμμα): σειρά με την οποία καλούνται οι πράξεις φόρτωσης/αποθήκευσης από το πρόγραμμα Πρώτα op1 και μετά op2: op1 op2 (op1 p op2) Memory order (σειρά στην μνήμη): σειρά με την οποία εκτελούνται οι πράξεις φόρτωσης/αποθήκευσης στην μνήμη Πρώτα op1 και μετά op2: op1 op2 (op1 m op2) ΙΙΙ 8 lalis@inf.uth.gr
Sequential Consistency (SC) Απαιτήσεις ως προς την σειρά εκτέλεσης Load-Load: L(a) L(b) L(a) L(b) Load-Store: L(a) S(b) L(a) S(b) Store-Load: S(a) L(b) S(a) L(b) Store-Store: S(a) S(b) S(a) S(b) Απαιτήσεις ως προς την επικαιρότητα φόρτωσης Freshness: L(a) = MostRecent{ S(a) S(a) L(a) } ΙΙΙ 9 lalis@inf.uth.gr
Παράδειγμα int x=0; int y=0; P1: x=1; // store(x) r1=y; // load(y) P2: y=1; // store(y) r2=x; // load(x) Program order @ P1: store(x) load(y) Program order @ P2: store(y) load(x) Πιθανά(;) αποτελέσματα r1==1 && r2==0 r1==0 && r2==1 r1==1 && r2==1 r1==0 && r2==0 SC non SC ΙΙΙ 10 lalis@inf.uth.gr
p @P1 m p @P2 SC x=1; r1=y; 0 1 y=1; r2=x; p @P1 m p @P2 non SC x=1; r1=y; 0 0 y=1; r2=x; ΙΙΙ 11 lalis@inf.uth.gr
Θεωρητικό μοντέλο SC CPU CPU CPU switch memory Η σύνδεση με την μνήμη γίνεται μέσω διακόπτη, που αλλάζει θέση (επιλογή CPU) περιοδικά Η επιλεγμένη CPU εκτελεί τις πράξεις εν σειρά Οι πράξεις εξυπηρετούνται μόνο όταν υπάρχει σύνδεση με την μνήμη, διαφορετικά μπλοκάρουν ΙΙΙ 12 lalis@inf.uth.gr
Total Store Order (TSO) Απαιτήσεις ως προς την σειρά εκτέλεσης Load-Load: L(a) L(b) L(a) L(b) Load-Store: L(a) S(b) L(a) S(b) Store-Load: S(a) L(b) S(a) L(b) Store-Store: S(a) S(b) S(a) S(b) ευελιξία (FIFO write buffer) Απαιτήσεις ως προς την επικαιρότητα φόρτωσης Freshness: L(a) = MostRecent{ S(a) S(a) L(a) or S(a) L(a)} το πιο πρόσφατο store στον write buffer ή (αν δεν υπάρχει εκεί) στην μνήμη ΙΙΙ 13 lalis@inf.uth.gr
Παράδειγμα int x=0; int y=0; P1: x=1; // store(x) r1=y; // load(y) P2: y=1; // store(y) r2=x; // load(x) Program order @ P1: store(x) load(y) Program order @ P2: store(y) load(x) Πιθανά(;) αποτελέσματα r1==1 && r2==0 r1==0 && r2==1 r1==1 && r2==1 r1==0 && r2==0 TSO & SC TSO, but non SC ΙΙΙ 14 lalis@inf.uth.gr
p @P1 m p @P2 TSO but non SC x=1; r1=y; 0 0 y=1; r2=x; p @P1 m p @P2 TSO but non SC x=1; r1=y; 0 0 y=1; r2=x; ΙΙΙ 15 lalis@inf.uth.gr
Θεωρητικό μοντέλο TSO CPU CPU CPU FIFO write buffer switch memory Η σύνδεση με την μνήμη γίνεται μέσω διακόπτη Η αποθήκευση γίνεται σε τοπικό FIFO write buffer και περνιέται αργότερα/ασύγχρονα στην μνήμη Η ανάγνωση/φόρτωση γίνεται με προτεραιότητα από τον write buffer, διαφορετικά από την μνήμη ΙΙΙ 16 lalis@inf.uth.gr
Memory fences/barriers Λόγω της φύσης του κώδικα των προγραμμάτων, τις περισσότερες φορές το TSO είναι ισοδύναμο με το SC Πως μπορούμε (αν το θελήσουμε) να «εκβιάσουμε» λειτουργικότητα SC σε ένα σύστημα που είναι TSO; Να είμαστε σίγουροι ότι οι όποιες αποθηκεύσεις έγιναν από το πρόγραμμα θα περαστούν στην μνήμη προτού γίνει η «επόμενη» φόρτωση Fence/barrier: ρητή αίτηση να περαστούν στην μνήμη όλες οι αποθηκεύσεις που βρίσκονται ακόμα σε εκκρεμότητα μέσα στον write buffer (flush) Η CPU μπλοκάρει μέχρι αυτό να ολοκληρωθεί ΙΙΙ 17 lalis@inf.uth.gr
Fence extensions for TSO Απαιτήσεις ως προς την σειρά εκτέλεσης Load-Fence: L(a) Fence L(a) Fence Store-Fence: S(a) Fence S(a) Fence Fence-Load: Fence L(a) Fence L(a) Fence-Store: Fence S(a) Fence S(a) Fence-Fence: Fence Fence' Fence Fence' Καθώς το «απλό» TSO ήδη σειριοποιεί τις περισσότερες πράξεις μεταξύ τους, το παραπάνω είναι ισοδύναμο με Fence-Load: Fence L(a) Fence L(a) Store-Fence: S(a) Fence S(a) Fence ΙΙΙ 18 lalis@inf.uth.gr
Παράδειγμα int x=0; int y=0; P1: x=1; // store(x) FENCE; r1=y; // load(y) P2: y=1; // store(y) FENCE; r2=x; // load(x) Program order @ P1: store(x) Fence load(y) Program order @ P2: store(y) Fence load(x) Πιθανά(;) αποτελέσματα r1==1 && r2==0 r1==0 && r2==1 r1==1 && r2==1 r1==0 && r2==0 TSO & SC non TSO+fence, non SC ΙΙΙ 19 lalis@inf.uth.gr
Πιο «χαλαρά» μοντέλα συνέπειας Το SC/TSO έχει πολλές απαιτήσεις σειριοποίησης Περιορίζεται η ευελιξία που έχει μια CPU ως προς την σειρά με την οποία μπορεί να εκτελέσει τις εντολές που δίνει ο προγραμματιστής όμως αυτή η ευελιξία μπορεί να είναι σημαντική για την απόδοση Αυτή η αυστηρή σειριοποίηση δεν είναι πάντα απαραίτητη για την ορθότητα των προγραμμάτων Μπορεί να υπάρξει μεγαλύτερη ευελιξία! ΙΙΙ 20 lalis@inf.uth.gr
Παράδειγμα int x=0; int y=0; int flag=0; P1: x=1; // store(x) y=1; // store(y) flag=1; // store(f) P2: L: r1=flag; // load(flag) if (!r1) goto L; r2=x; // load(x) r3=y; // load(y) Παρότι οι εντολές δίνονται με συγκεκριμένη σειρά, ο προγραμματιστής συνήθως επιθυμεί, στο τέλος να ισχύει ότι: r2==1 && r3==1 Αυτό είναι εγγυημένο με SC & TSO Αλλά μπορεί να γίνει με λιγότερη σειριοποίηση από αυτή που επιβάλλει το SC & TSO ΙΙΙ 21 lalis@inf.uth.gr
Παράδειγμα int x=0; int y=0; int flag=0; P1: x=1; // store(x) y=1; // store(y) flag=1; // store(f) P2: L: r1=flag; // load(flag) if (!r1) goto L; r2=x; // load(x) r3=y; // load(y) SC/TSO: υπερβολική σειριοποίηση store(x) store(y) store(flag) load(flag)=1 load(x) load(y) Flexible: store(y) store(x) store(flag) load(flag)=1 load(y) load(x) ΙΙΙ 22 lalis@inf.uth.gr
Relaxed consistency with fences Δεν δίνεται καμία εγγύηση για την σχετική σειρά με την οποία θα γίνουν οι πράξεις στην μνήμη Η όποια επιθυμητή σειριοποίηση πρέπει να προσδιοριστεί ρητά, μέσω εντολών fence Εγγυάται ότι όλες οι πράξεις που προηγούνται θα ολοκληρωθούν πριν από τις πράξεις που έπονται X1 X2 Xn Fence Υ1 Υ2 Υm {X1,X2,,Xn} Fence {Υ1,Υ2,,Υm} οποιαδήποτε σειρά, εκτός αν υπάρχουν εξαρτήσεις (περισσότερες πράξεις πάνω στην ίδια θέση μνήμης) ΙΙΙ 23 lalis@inf.uth.gr
Relaxed Consistency (RLX) Απαιτήσεις για πράξεις σε διαφορετικές διευθύνσεις Load/Store-Fence: L/S(a) Fence L/S(a) Fence Fence-Load/Store: Fence L/S(a) Fence L/S(a) Fence-Fence: Fence Fence' Fence Fence' Απαιτήσεις για πράξεις στην ίδια διεύθυνση (TSO) Load-Load: L(a) L'(a) L(a) L'(a) Load-Store: L(a) S(a) L(a) S(a) Store-Store: S(a) S'(a) S(a) S'(a) Απαιτήσεις ως προς την επικαιρότητα φόρτωσης (TSO) Freshness: L(a) = MostRecent{ S(a) S(a) L(a) or S(a) L(a) } ΙΙΙ 24 lalis@inf.uth.gr
Παράδειγμα int x=0; int y=0; int flag=0; P1: x=1; // store(x) y=1; // store(y) FENCE; flag=1; // store(f) P2: L: r1=flag; // load(flag) if (!r1) goto L; FENCE; r2=x; // load(x) r3=y; // load(y) Στο τέλος σίγουρα ισχύει: r2==1 && r3==1 Χωρίς να προδιαγράφεται η σχετική σειρά αποθήκευσης των τιμών των x και y από το P1 Χωρίς να προδιαγράφεται η σχετική σειρά φόρτωσης των τιμών των x και y από το P2 ΙΙΙ 25 lalis@inf.uth.gr
Παράδειγμα int x=0; int y=0; int flag=0; P1: x=1; // store(x) y=1; // store(y) FENCE; flag=1; // store(f) P2: L: r1=flag; // load(flag) if (!r1) goto L; FENCE; r2=x; r3=y; // load(x) // load(y) γιατί χρειάζεται αυτό το fence; Στο τέλος σίγουρα ισχύει: r2==1 && r3==1 Χωρίς να προδιαγράφεται η σχετική σειρά αποθήκευσης των τιμών των x και y από το P1 Χωρίς να προδιαγράφεται η σχετική σειρά φόρτωσης των τιμών των x και y από το P2 ΙΙΙ 26 lalis@inf.uth.gr
Θεωρητικό μοντέλο RLX CPU CPU CPU reorder reorder reorder reorders loads & stores based on RLX rules switch memory Κάθε CPU εκτελεί τις πράξεις εν σειρά Οι πράξεις περνάνε μέσα από μια μονάδα αναδιάταξης που μπορεί να αλλάξει την σειρά τους, προτού τις προωθήσει μέσω του διακόπτη στην μνήμη Η μονάδα αναδιάταξης σέβεται τους κανόνες RLX ΙΙΙ 27 lalis@inf.uth.gr
Ευελιξία: non-fifo coalescing write buffer Με TSO οι αποθηκεύσεις μπορούν να γίνουν άμεσα, στον write buffer, χωρίς επικοινωνία με την μνήμη Όμως πρέπει να τηρείται αυστηρά σειρά Store-Store, ακόμα και για διαφορετικές θέσεις μνήμης, που αυξάνει την πολυπλοκότητα διαχείρισης S(a) S(b) S'(a) S(a) S(b) S'(a) Με RLX η αποθήκευση μιας νέας τιμής σε θέση μνήμης για την οποία ήδη υπάρχει εκκρεμής αποθήκευση στον write buffer μπορεί να προσπεράσει χρονολογικά προηγούμενες αποθηκεύσεις για άλλες θέσεις μνήμης S(a) S(b) S'(a) S(b) S'(a) ΙΙΙ 28 lalis@inf.uth.gr
Συγχρονισμός με TSO και RLX TSO int lck=0; // other shared vars L: r=tas(&lck); // load-store if (r) goto L; // loads & stores in CS lck=0; // store RLX int lck=0; // other shared vars L: r=tas(&lck); // load-store if (r) goto L; FENCE; // loads & stores in CS FENCE; lck=0; // store η φόρτωση των τιμών των μεταβλητών που θα χρησιμοποιηθούν στο ΚΤ γίνεται μετά το κλείδωμα οι αλλαγές στις τιμές των μεταβλητών που έγιναν στο ΚΤ αποθηκεύονται προτού γίνει το ξεκλείδωμα ΙΙΙ 29 lalis@inf.uth.gr
SC for Data-Race-Free (DRF) programs Data race: ανταγωνισμός πάνω σε κοινά δεδομένα Υπάρχει όταν δύο νήματα προσπελάζουν την ίδια θέση μνήμης και τουλάχιστον ένα νήμα γράφει σε αυτήν, χωρίς να υπάρχει κάποιος ρητός συγχρονισμός SC for DRF (programmer): ο προγραμματιστής είναι υπεύθυνος να γράφει κώδικα που δεν έχει data races υπό την προϋπόθεση ότι η πλατφόρμα εγγυάται SC SC for DRF (provider): αυτός που υλοποιεί την πλατφόρμα εκτέλεσης RLX είναι υπεύθυνος έτσι ώστε η εκτέλεση SC-DRF κώδικα να είναι ισοδύναμη με μια εκτέλεση του κώδικα υπό SC Αυτή η σύμβαση ισχύει για όλα τα γνωστά συστήματα ΙΙΙ 30 lalis@inf.uth.gr
Παράδειγμα int x=0; int y=0; πιθανά αποτελέσματα με RLX: r1=0 && r2==0 r1=1 && r2==0 r1=1 && r2==1 r1=0 && r2==1 P1: x=1; // store(x) y=1; // store(y) P2: r1=x; r2=y; // load(x) // load(y) Το πρόγραμμα έχει data races (δεν είναι DRF) Το αποτέλεσμα της εκτέλεσης εξαρτάται από την (τυχαία) σχετική σειρά με την οποία κάθε νήμα θα προσπελάσει την μνήμη ακόμα και αν υπάρχει SC Δεν δίνεται καμία εγγύηση για το αποτέλεσμα της εκτέλεσης πάνω από μια πλατφόρμα RLX/SC-DRF ΙΙΙ 31 lalis@inf.uth.gr
Παράδειγμα int x=0; int y=0; int lck=0; P1: LOCK(&lck); // FENCE x=1; // store(x) y=1; // store(y) UNLOCK(&lck); // FENCE πιθανά αποτελέσματα με RLX: r1=0 && r2==0 r1=1 && r2==1 P2: LOCK(&lck); // FENCE r1=x; // load(x) r2=y; // load(y) UNLOCK(&lck); // FENCE Το πρόγραμμα δεν έχει data races (είναι DRF) Το αποτέλεσμα της εκτέλεσης πάνω από μια πλατφόρμα RLX/SC-DRF είναι εγγυημένα συμβατό με αυτό μιας πλατφόρμας SC ΙΙΙ 32 lalis@inf.uth.gr
Memory model γλωσσών ψηλού επιπέδου Θεωρητικά, κάθε γλώσσα πρέπει να ορίζει το μοντέλο συνέπειας μνήμης που παρέχει ανεξάρτητα από την πλατφόρμα εκτέλεσης: συνήθως SC-DRF ιδιαίτερα σημαντικό υπό ταυτόχρονη εκτέλεση Οι μεταγλωτιστές μπορεί να επιφέρουν και αυτοί αλλαγές στην σειρά των πράξεων μνήμης, σε πιο ψηλό επίπεδο, λόγω χρήσης καταχωρητών Πρέπει να γίνει ρητή δήλωση των μεταβλητών που χρησιμοποιούνται σε σχήματα συγχρονισμού (π.χ., volatile), ώστε οι αλλαγές να περνάνε στην μνήμη και να μην μένουν σε «τοπικό» επίπεδο ΙΙΙ 33 lalis@inf.uth.gr
Παράδειγμα Α L1: load r1 a X1: mul r2 rl 2 S1: store b r2 L2: load r3 c L3: load r4 a X2: sub r5 r3 r4 S2: store d r5 b = 2*a; d = c-a; Β L1,L3: load r1 a X1: mul r2 rl 2 S1: store b r2 L2: load r2 c /* moved to top */ X2: sub r2 r2 r1 S2: store d r2 L1 S1 L2 L3 S2 p m αν ένα άλλο νήμα αλλάξει την τιμή του a στο σημείο αυτή η αλλαγή δεν θα είναι ορατή στην έκδοση Β αυτό δεν είναι πρόβλημα για μεταβλητές που προσπελάζονται με race free τρόπο, αλλά είναι πρόβλημα για κοινές μεταβλητές που χρησιμοποιούνται σε σχήματα συγχρονισμού L1 S1 L2 L3 S2 p m ΙΙΙ 34 lalis@inf.uth.gr
Αποφυγή μπλοκαρίσματος με caching Συνήθως δεν υφίσταται πραγματικός/ουσιαστικός ανταγωνισμός μεταξύ των CPU, που μπορεί να προσπελάζουν άσχετες θέσεις μνήμης Βελτιστοποίηση: Το υποσύστημα μνήμης δίνει στις CPU/διεργασίες άδειες χρήσης για συγκεκριμένες θέσεις μνήμης Οι άδειες δίνονται στο πνεύμα των readers-writers Μπορεί να χρησιμοποιηθεί κρυφή μνήμη για την αποφόρτιση του κυρίως υποσυστήματος μνήμης (και για μείωση της κίνησης στο bus/interconnect) Μπορεί βελτιωθεί η απόδοση των παραπάνω μοντέλων συνέπειας μνήμης, π.χ., του SC ΙΙΙ 35 lalis@inf.uth.gr
Ευέλικτη υλοποίηση SC CPU CPU CPU cache cache cache cache-coherent memory subsystem άδειες πρόσβασης Κάθε CPU καλεί τις πράξεις εν σειρά Μια πράξη μπορεί να πραγματοποιηθεί μέσω της cache, ταυτόχρονα με τις πράξεις άλλων CPU, εφόσον έχει ληφθεί η κατάλληλη άδεια πρόσβασης Η αίτηση-λήψη αδειών πρόσβασης μπλοκάρει ΙΙΙ 36 lalis@inf.uth.gr
Άδειες πρόσβασης M (modifiable): διάβασμα/αλλαγή από έναν S (shared): διάβασμα από πολλούς ταυτόχρονα Η CPU ζητά και περιμένει να λάβει κατάλληλες άδειες προτού χρησιμοποιήσει τις θέσεις μνήμης Επιτυγχάνεται η επιθυμητή συνέπεια, αφήνοντας αρκετές ευκαιρίες για παράλληλη εκτέλεση Σημείωση: Οι άδειες δεν «κλειδώνουν» μια άδεια μπορεί να «χαθεί» λόγω αίτησης από άλλη CPU (μπορεί να γίνει αναστολή επεξεργασίας αιτήσεων) ΙΙΙ 37 lalis@inf.uth.gr
CPU1 CPU2 CPU3 CPU4 store(a) store(b) load(c) load(c) a:1 (M) b:0 (M) c:5 (S) c:5 (S) cache cache cache cache οποιαδήποτε σειρά είναι συνεπής με SC memory m CPU1: store(a) CPU2: store(b) CPU4: load(c) CPU3: load(c) ΙΙΙ 38 lalis@inf.uth.gr
Speculative execution Η CPU δεν περιμένει μέχρι να λάβει τις κατάλληλες άδειες για τις θέσεις μνήμης που χρησιμοποιεί Εφόσον υπάρχουν τα δεδομένα στην cache, προχωρά με την εκτέλεση του προγράμματος, υποθέτοντας ότι δεν θα υπάρξει ανταγωνισμός Υπάρχει πιθανότητα ασυνέπειας Προτού «περαστούν» τα αποτελέσματα της εκτέλεσης στην μνήμη, πρέπει να γίνει έλεγχος ότι όντως δεν υπήρξε ανεπιθύμητος ανταγωνισμός Διαφορετικά, η εκτέλεση πρέπει να ακυρωθεί και να επαναληφθεί από την αρχή (rollback) Σημείωση: Η εκτέλεση ίσως πρέπει να ακυρωθεί έτσι και αλλιώς (π.χ., speculative branch taking) ΙΙΙ 39 lalis@inf.uth.gr
Ατομικές εντολές Read-Modify-Write Ατομική εκτέλεση των αντίστοιχων load/store SC: 1) lock mem, 2) load-exec-store, 3) unlock mem SC/cache: 1) get M lock, 2) suspend cache protocol, 3) load-exec-store, 4) resume cache protocol TSO: 1) flush write buffer, 2) lock mem, 3) load-exec-store*, 4) unlock mem TSO/cache: 1) flush write buffer, 2) get M lock, 3) suspend cache protocol, 4) load-exec-store*, 5) resume cache protocol (store*) direct store (bypassing the write buffer) ΙΙΙ 40 lalis@inf.uth.gr