• H υλοποίηση με threads ήταν η πιο δύσκολη και χρονοβόρα υλοποίηση σε όλο το project. Και αυτό διότι απαιτούσε ένα μη-ντετερμινιστικό πρόβλημα (χρονοπρογραμματισμός των threads από το λειτουργικό σύστημα) να αναχθεί σε ντετερμινιστικό , γεγονός που απαιτούσε πολύ καλό συγχρονισμό των threads.

• Συγκεκριμένα το πρόβλημα ήταν στην κοινή συνθήκη τερματισμού. Εαν το project ζητούσε κάθε thread να επεξεργάζεται κάποιο τμήμα του πίνακα για π.χ. 100 επαναλήψεις τότε η υλοποίηση θα είχε επιτευχθεί πολύ γρήγορα. Διότι το πρώτο πρόβλημα που είχα να αντιμετοπίσω ήταν να συχρονιστούν τα threads σε επίπεδο επανάληψης. Δηλαδή τα threads να επεξεργάζονται στοιχεία στην ίδια επανάληψη και να πηγαίνουν σε επόμενη μόνο όταν τελειώσουν στην τρέχων επανάληψη. Αυτό δεν θα μπορούσε να γίνει παρά μόνον με την προσθήκη μιας μεταβλητής barrier στο τέλος κάθε επανάληψης. Ενδιαφέρον είναι η περίπτωση που τα thread δεν ειναι συγχρωνισμένα. Παραθέτω εικόνα που αποδυκνείουν την λανθασμένη υλοποίηση όταν δεν χρησιμοποιώ barrier για 1431 επαναλήψεις (δεν χρησιμοποιώ περισσότερες γιατί τα 'σφάλματα' στην εικόνα αλλιώνονται με το πέρασμα του αλγορίθμου Jacobi)

• 
  Λανθασμένη υλοποίηση χωρίς συγχρονισμό των threads.

.

• Για να πετύχω σωστό συγχρονισμό χρειάστηκε τελικά να χρησιμοποιήσω 3 μεταβλητές τύπου barrier , 3 μεταβλητές-κλειδιά (mutex) και 1 μεταβλητή τύπου condition variable. Μια από κάθε μια από τις προηγούμενες χρειάζονται για σωστή αρχικοποίηση των threads. Στην ουσία κάθε thread που αρχικοποιείται παίρνει ένα κλειδί , πάιρνει τις απαραίτητες παραμέτρους , και μέσω της condition variable ειδοποιεί τα άλλα thread να αρχικοποιηθούν και αυτά και αφήνει το κλειδί. Στην συνέχεια χρησιμοποιώ μια barrier ωστέ να ακολουθήσει κοινός τερματισμός των threads.

• Προκειμένου να πετύχω σωστό συγχρονισμό στην συνθήκη τερματισμού χρειάστηκε να δημιουργήσω έναν πίνακα ο οποίος θα κρατάει τιμές για το πόσες φορές κάποιο thread έχει συγλίνει στο τμήμα του πίνακα που επεξεργάζεται. Ο πίνακας ε'ιναι κοινός για όλα τα thread και γίνεται πρόσβαση σε αυτόν μέσω συνάρτησης σε περιβάλλον mutex-lock-unlock. Όταν κάποιο thread διαπιστώσει ότι όλα τα thread έχουν συγκλίνει και κάποιο από όλα έχει συγκλίνει 1 φορά , τότε αυτό είναι το τελευταίο thread που συνέκλινε και άρα το πρόγραμμα πρέπει να τερματίσει. Τα υπόλοιπα threads θα δουν ότι πρέπει να τερματίσουν και δεν θα προχωρήσουν σε νεο γύρο επεξεργασίας.

• Για εκτέλεση με διαφορετικό αριθμό threads η σύγλιση γινόταν όπως και στην ακολουθιακή εκτέλεση στις 15131 επαναλήψεις , οπότε και η εικόνα είναι η ίδια :

Υλοποίηση με σωστό συγχρονισμό των threads. Εικόνα σε format .ppm

Εικόνα εξόδου από gnuplot από format εξόδου .txt

• Παραθέτω μια εικόνα που δείχνει τα αποτελέσματα των χρόνων εκτέλεσης του project στον server eteocles@ceid.upatras.gr . Tα αποτελέματα είναι εκπληκτικά πιο γρήγορα σε σχέση με την εκτέλεση τόσο στο σταθερό pc μου (~240 seconds - 4 threads) , (AMD 4200+ (2 cores @ 2,2GHz - 2Mb L2 cache) , 2Gb Ram@400MHz , OpenSuse 10.2 x86-64 ) όσο και στο laptop (~180 seconds - 4 threads) (Intel core 2 Duo , 2Gb Ram @ 667<Mhz ,Fedora Core 9 ), γι'αυτό προτίμησα να δείξω τα αποτελέσματα από την εκτέλεση στον server.

• Όπως φαίνεται απ΄την παραπάνω εικόνα η γρηγορότερη εκτέλεση επιτυγχάνεται όταν χρησιμοποιώ 4 threads. Αυτό είναι λογικό εφόσον ο server διαθέτει 4 επεξεργατές. Παραθέτω και μια εικόνα που φανερώνει το hardware synthesis του server.