THMMY.gr

Μίλησα με τον διδάσκοντα και είπε να δημιουργήσουμε ένα τόπικ ΓΙΑ ΑΠΟΡΙΕΣ σχετικά με την εργασία και να του στείλουμε το link ώστε να μπορούμε να επικοινωνούμε.
Εγώ είμαι ακόμα σε φάση που προσπαθώ να καταλάβω τα pthreads :P
Θα αργήσω λιγάκι να μπω στην φάση των αποριών πάνω στην εργασία.

Ισχύει το ότι μπορούμε να παραδώσουμε την εργασία μέσα στο καλοκαίρι;
Ή η 16/6/2011 είναι η καταληκτική ημερομηνία παράδοσης; (Δε νομίζω..)

Επειδη μιλαγαμε σημερα με τον Τζιμμακο

τελικα ασχοληθηκε κανενας ακομα η μετα τις εξετασεις?

Μεχρι 31 Αυγουστου πλεον.

Είναι σίγουρο αυτό; Το είπε μέσα στην τάξη; Γιατί στο ethmmy δε λέει τίποτα και εγώ θυμάμαι μέσα στην τάξη να δίνει μία άλλη ημερομηνία αλλά όχι τόσο αργά. Νομίζω - και δεν παίρνω όρκο - κάπου μέσα στον Ιούλιο :-\

εμένα μια φορά που του είπα δεν προλαβαίνω μου είπε "από σεπτέμβρη",
αν είναι για μέσα στον ιούλιο, πάει, κάηκε η εργασία και προφανώς όχι λόγω καύσωνα

Από Σεπτέμβρη; Δηλαδή, ότι την πάτησες, ξαναδήλωσε το μάθημα; Ή ότι δέχεται και μέχρι σεπτέμβρη;

Παιδια ο πιτσιανης ειναι πολυ ελαστικος και εχει κατανοηση..

Δεν θα σας πηδηξει σε καμμια περιπτωση.

31 Αυγούστου είναι η προθεσμία.
Θυμάμαι που το είπε σε ένα απο τα 2 τελευταία μαθήματα.
Το "απο Σεπτέμβρη" σημαίνει ότι τότε θα παρεις το βαθμό σου...

Στους κανόνες που πρέπει να είναι σε ισχύ τι εννοούμε με την φράση:
Εφικτές συναλλαγές μεταξύ Limit εκτελούνται στη μέση τιμή του spread (τιμή αγοράς - τιμή πώλησης).

Δλδ αυτό που δεν καταλαβαίνω, είναι οι περιορισμοί που υπάρχουν ώστε μια συναλλαγή μεταξύ limit να μην θεωρείται εφικτή.
Ο μόνος περιορισμός που μπορώ να σκεφτώ είναι να μην υπάρχουν καθόλου εντολές Market.
Είναι όντως αυτός ο μοναδικός περιορισμός;

Από ότι έχω καταλάβει μέχρι τώρα εφικτές συναλλαγές μεταξύ limit είναι αυτές για τις οποίες:

επιθυμητή τιμή αγοράς > επιθυμητή τιμή πώλησης.

Εκτελώντας το marketSim διαπιστώνω ότι ο producer παράγει πιο γρήγορα από ότι ο consumer καταναλώνει. Ακόμα δεν έχω γράψει κώδικα στο σώμα της void *Cons( void *arg ). Είναι φυσιολογικό αυτό που συμβαίνει; Δεν έρχεται σε αντιδιαστολή με το real- timeness που θέλουμε να πετύχουμε ;

επιθυμητή τιμή αγοράς δλδ θέλω να αγοράσω στα 99.5 ευρώ
επιθυμητή τιμή πώλησης δλδ θέλω να πουλήσω στα 99.5 ευρώ
δεκτή συναλλαγη σύμφωνα με την λογική σου (αν κατάλαβα καλά).
αφού η μέση τιμή του spread θα είναι 99.5 ποιο το νόημα να εκτελεστεί στη μέση τιμή του spread και να αλλάξουμε σχετικά το currentPriceX10 με την μέση τιμή του spread (κάνοντας τις αντίστοιχες πράξεις για την εύρεση του) ενώ μπορούμε να το αντικαταστήσουμε απλά με την τιμή (αγοράς ή πώλησης) από τις δυο παραπάνω συναλλαγές;

Σύμφωνα με όσα κατάλαβα εγώ:
υπάρχουν μόνο εντολές limit στις ουρές μας. Καθόλου Market.
Από εδώ ξεκινάνε δυο σενάρια.
Το ένα είναι να πουλάει φθηνά ο ένας και ο άλλος να αγοράζει ακριβά επομένως κάνοντας την συναλλαγή στην μέση τιμή του spread βγαίνουν και οι δυο κερδισμένοι.
Το άλλο είναι ο ένας να πουλάει ακριβά και ο άλλος να αγοράζει φθηνά. Επομένως αν κάνουμε την συναλλαγή στη μέση τιμή του spread θα βγουν και οι δυο "χαμένοι". πρέπει να βάλουμε έλεγχο ώστε να μην επιτρέπονται τέτοιες συναλλαγές ή έτσι δουλεύει το χρηματηστήριο σε αυτές τις περιπτώσεις;

μέση τιμή του spread την καταλαβαίνω ως (τιμή αγοράς + τιμή πώλησης)/2...

Όσον αφορά το real timeness αυτό που έχω καταλάβει και από το μάθημα είναι ότι από την στιγμή που έρχεται μια εντολή θα πρέπει να διεκπεραιωθεί σε ένα μικρό χρονικό διάστημα (έως και ακαριαία :P). Το κατα πόσο το σύστημα μας είναι real-time θα το δούμε στο τέλος αφού το ολοκληρώσουμε. Αν το έχεις ολοκληρώσει και σου αργεί να καταναλώσει εντολές σε σχέση με τον μέσο ρυθμό που παράγονται τότε ναι, έρχεται σε αντιδιαστολή με το real-timeness. :P

σωστό είναι, το ίδιο με αυτό που λέω εγώ με άλλα λόγια, απλά δεν είχα μεριμνήσει στην αρχή για έλεγχο τιμής αγοράς limit sell να είναι μεγαλύτερη ή ίση από την τιμή πώλησης limit buy ώστε να είναι δίκαιη η συναλλαγή και να μην βρεθεί αυτός που αγοράζει στα 100 π.χ. να αγοράζει εν αγνοία του με 125.
Στο μόνο που κολλάω στην λογική σου είναι γιατί πρέπει απαραίτητα το current price να είναι μεταξύ αυτών των τιμών.
πες π.χ. το currentprice είναι στα 200 δολλάρια
και υπάρχει ένας που αγοράζει με 150 και ένας που πουλάει με 100.
αυτή η συναλλαγή δεν πρέπει να γίνει και να επανακαθοριστεί το current price στα 125 ευρώ;

έχω πρόβλημα με τις condition variables

τις ορίζω ως εξής εκτός main:
Code:
pthread_mutex_t begin_categ_mut;
pthread_cond_t begin_categ;
pthread_mutex_t begin_cons_mut;
pthread_cond_t begin_cons;

εντός main τις αρχικοποιώ ως εξής:
Code:
pthread_mutex_init(&begin_categ_mut, NULL);
pthread_cond_init(&begin_categ,NULL);
pthread_mutex_init(&begin_cons_mut, NULL);
pthread_cond_init(&begin_cons,NULL);

μέσα στην cons αν δεν βρει καμία ενεργή συναλλαγή θέλω να ξεκινάει το νήμα κατηγοριοποιήσης.
Για να το πετύχω αυτό στην αρχή του νήματος μετά το while(1){ γράφω

Code:
printf("locking begin cons mutex\n");
pthread_mutex_lock(&begin_cons_mut);
printf("locking begin categ mutex\n");
pthread_mutex_lock(&begin_categ_mut);

και με το πέρας των ελέγχων αφού δεν βρει καμιά επιτρεπτή συναλλαγή εκτελεί το εξής:

Code:
printf("Signaling CatOrd\n");
printf("%d\n",begin_categ);
pthread_cond_signal(&begin_categ);
printf("%d\n",begin_categ);
printf("unlocking begin categ mutex\n");
pthread_mutex_unlock(&begin_categ_mut);

στο νήμα κατηγοριοποίησης μετά το while(1){ εκτελεί τα εξής:

Code:
printf("locking begin cons mutex\n");
pthread_mutex_lock(&begin_cons_mut);
printf("locking begin categ mutex\n");
pthread_mutex_lock (&begin_categ_mut);
printf("waiting begin categ signal\n");
pthread_cond_wait(&begin_categ, &begin_categ_mut);
printf("CatOrd running\n");

Η έξοδος που παίρνω είναι:

Cons running
locking begin cons mutex on Cons
locking begin categ mutex on Cons
locking begin cons mutex on CatOrd
Signaling CatOrd from Cons
0
0
unlocking begin categ mutex on Cons
Waiting begin cons signal on Cons
locking begin categ mutex on Catord
waiting begin categ signal on CatOrd
*** Incoming Order Queue is FULL.

το αποτέλεσμα είναι όπως φαίνεται και στην έξοδο του προγράμματος να μην στέλνει το signal &begin_categ στο νήμα κατηγοριοποίησης και το πρόγραμμα να κολλάει σε ένα βρόγχο αναμονής (για πάντα).

επειδή δεν έχω πάρει παράλληλα και διανεμημένα και επειδή καλά τα λέει το POSIX αλλά άκρη δεν έβγαλα τις τελευταίες δυο ημέρες, μπορεί κάποιος να βοηθήσει να το ξεbugάρω;

Το current price πρέπει να είναι μεταξύ των δύο τιμών ώστε να ικανοποιούνται οι συνθήκες αγοράς και πώλησης που δίνονται εξ ορισμού για τις δύο limit εντολές.
Στο παράδειγμα που έδωσες με currentPrice = 200 αυτός που αγοράζει με 150 δεν μπορεί να αγοράσει ( η buy limit order εκτελείται όταν η currentPrice είναι μικρότερη από 150 ).  Right?

μπορεί να αγοράσει μόνο ΑΝ υπάρχει limit Sell που πουλάει κατω από 150 όσο και να 'ναι το currentPrice από την προηγούμενη συναλλαγή. Π.χ. στην προηγούμενη συναλλαγή μπορεί κάποιος να έστειλε το currentPrice στα ύψη αλλά τώρα να μην υπάρχει κανείς που να θέλει να αγοράσει τόσο ακριβά. Αυτό που λες ότι δεν μπορεί να αγοράσει δεν ισχύει, γιατί αν ήταν έτσι το currentPrice θα έφτανε στο άπειρο.

ΠΟΣΟ μας τρολλαρε ο Πιτσιανης οτι η εργασια ειναι 3 μερες υποθεση?

ΠΟΣΟ ΟΜΩΣ ???  :D

real life troll awardzzz  ;D

αλήθεια λέει, 3 μέρες υπόθεση είναι να γίνει η εργασία.
Απλά δεν ανέφερε πόσες μέρες υπόθεση είναι να αποκτήσεις το απαραίτητο υπόβαθρο για να την ξεκινήσεις.
Ξεκίνα την τώρα και 'συ να μαζευόμαστε σιγά σιγά περισσότεροι να βγάλουμε άκρη πιο γρήγορα γιατί έχουμε και άλλα μαθήματα που περιμένουν στην "queue".
Ήδη με το βοήθημα που μου στειλες στα condition variables δούλεψε και δεν ξέρω και 'γω πόσα μελλοντικά 24ωρα άκαρπων προσπαθειών έσωσα.

ΥΓ. αυτό (https://computing.llnl.gov/tutorials/pthreads/) καλά τα λέει αλλά μόνο με αυτό δουλειά δεν γίνεται.

βασικα ειχα και καναδυο βιβλια που ειχα διαβασει γενικα για παραλληλα και ειδικα για

C threading, απλα χαθηκανε και αυτα και σιγα σιγα απο τορρεντζ αμα τα κσαναβρω


--επισης αμα αρχισω να γραφω κωδικα μεσα στον Ιουλιο παιζει και να τελειωσω καποτε...@!

Με μία πρώτη ματιά ίσως έχεις deadlock στο παραπάνω κομμάτι κώδικα.

Κλειδώνεις αρχικά 2 mutexes, και μετά κάνεις w8 σε μια condition variable ουσιαστικά ξεκλειδώνοντας το ένα mutex αλλά αφείνωντας το άλλο κλειδωμένο. Οπότε αν ένα αλλο thread επιχειρήσει να κάνει pthread_mutex_lock(&begin_cons_mut) έχεις deadlock.

Αλλά αυτό είναι μόνο μια υπόθεση αφού έχεις ποστάρει μόνο κομμάτια κώδικα.
Σε τέτοιες περιπτώσεις το καλυτερο εργαλείο να χρησιμοποιήσεις, σε linux, είναι το valgrind, και πιο συγκεκριμένα το helgrind
Briskei deadlocks και διαφορα άλλα προβλήματα με threads

http://valgrind.org/docs/manual/hg-manual.html

PS: χρησιμοποίησε τα [ code ] [/ code ] tags για να καταλαβένουμε τι διαβάζουμε.

Έχω ένα θέμα με τον consumer ο οποίος μου ρίχνει την τιμή της μετοχής συνεχώς με αποτέλεσμα στα πρώτα 2-3 λεπτά να πέφτει υπό του μηδέν.
Θέλω να βεβαιωθώ ότι δεν έχω λάθος στην λογική διεκπεραίωσης των συναλλαγών οπότε θα κάνω μια περιγραφή των διάφορων περιπτώσεων ύπαρξης ενεργών εντολών και πως ανταποκρίνεται στην κάθε περίπτωση η συνάρτηση κατανάλωσης.

Περίπτωση: Market Sell - Market Buy
Δεν επηρεάζεται το currentPrice.
Αυτό που έχει μεγαλύτερο όγκο παραμένει στην ουρά, το άλλο διαγράφεται.

Περίπτωση: Market Sell - Market Buy - Limit Sell
Αν υπάρχει τιμή της Limit Sell χαμηλότερη από το currentPrice κάνε συναλλαγή Market Buy - Limit Sell, αλλιώς κάνε συναλλαγή Market Buy - Market Sell.

Περίπτωση: Market Sell - Limit Buy - Market Buy - Limit Sell
Ξεκίνα με το Market Buy και το Limit Sell. αν υπάρχει τιμή χαμηλότερη του CurrentPrice κάνε την συναλλαγή, αλλιώς κάνε συναλλαγή με την Market Sell.
Έλεγξε αν η Market Sell είναι άδεια. Αν δεν είναι ξεκίνα συναλλαγή Market Sell - Limit Buy. Άν υπάρχει κάποιος που αγοράζει ακριβότερα από την CurrentPrice κάνε την συναλλαγή αλλιώς έλεγξε αν το Market Buy είναι άδειο. Αν δεν είναι κάνε την συναλλαγή Market Sell - Market Buy

Περίπτωση: Limit Sell - Limit Buy
Έλεγξε αν αυτός που πουλάει, πουλάει φθηνότερα απ' ότι αγοράζει ο Limit Sell τότε η τιμή είναι ο μέσος όρος των spread.

Περίπτωση: Limit Buy - Market Sell
η τιμή της μετοχής καθορίζεται ως το μέγιστο Limit Buy και γίνεται η συναλλαγή.

Περίπτωση: Limit Sell - Market Buy
η τιμή της μετοχής καθορίζεται ως η ελάχιστη τιμή των εντολών Limit Sell και γίνεται η συναλλαγή.

Περίπτωση: Market Buy - Limit Sell - Limit Buy
Αν ο μέσος όρος των σπρεντ των εντολών limit Sell και limit Buy είναι μεγαλύτερος από την τιμή του limit Sell τότε πούλα στον limit buy, αλλιώς πούλα στον Market Buy στην τιμή limit Sell.

Περίπτωση: Market Sell - Limit Sell - Limit Buy
Αν ο μέσος όρος των σπρέντ είναι μικρότερος από την τιμή αγοράς limit buy τότε αγόρασε από την limit Sell στον μέσο όρο των σπρέντ, αλλιώς αγόρασε από τον market sell στην τιμή limit Buy.

Περίπτωση: Market Sell - Market Buy - Limit Buy
Αν η τιμή limit buy είναι μεγαλύτερη του currentPrice τότε πούλα στον limit Buy αλλιώς πούλα στον Market Buy.

Πώς υπολογίζει κανείς τη μέση τιμή των spreads ; Εννοώ με ποια σειρά υπολογίζεται η διαφορά " τιμή αγοράς - τιμή πώλησης ";
( πχ Σειρά άφιξης των εντολών )

 

νόμιζα το λύσαμε αυτό με την συζήτηση που κάναμε τότε, μέση τιμή των spreads = (ordLB.price1 + ordLS.price1)/2 και η συναλλαγή είναι εφικτή όταν ordLS.price1<=ordLB.price1 ώστε να μην αναγκαστεί να αγοράσει ακριβότερα από όσο ορίζει ο ίδιος ο ένας και ο άλλος να έχει περιθώρια κέρδους
εγώ αυτό κατάλαβα.

Η "σειρά" που ακολούθησα εγώ είναι η εξής: Τραβάω το ελάχιστο στοιχείο από την queueLS τραβάζω το μέγιστο στοιχείο από την queueLB ελέγχω αν ισχύει η παραπάνω ανισότητα, αν ισχύει κάνε την συναλλαγή, αν δεν ισχύει βάλτα πάλι πίσω και πάνε να ελέγξεις ξανά ποιες ουρές είναι γεμάτες για να κάνεις την επόμενη συναλλαγή

Και εγώ έτσι το σκέφτηκα και έτσι σκόπευα να το υλοποιήσω μέχρι που είδα το παρακάτω και με μπέρδεψε:


Αν είναι να κάνεις τη συναλλαγή LimitSell - LimitBuy τότε θα ισχύει ordLS.price1 <= ordLB.price1 οπότε και ο μέσος όρος των σπρεντ θα είναι μικρότερος από την τιμή LimitSell. Μήπως παραπάνω αντί για LimitSell ήθελες να πεις currentPrice??

παιδια πρεπει να το τρεξουμε και στο Διαδη ή δεν εχει σημασια?

όχι γιατί οι συναλλαγές limit - market γίνονται στην τιμή limit. οπότε αφού ξέρεις ότι ο Market Buy θα την αγοράσει σίγουρα την μετοχή στην τιμή limit Sell απλά κοιτάς αν μπορείς να εξασφαλίσεις στην limit Sell κάποιο παραπάνω κέρδος. Αυτό έχω ως σκέψη για την συγκεκριμένη περίπτωση. Έστειλα email με το παραπάνω σεντόνι στον καθηγητή αλλά δεν απαντάει. Έχει 7-8 μέρες.
Βέβαια εγώ έχω ένα θέμα με τη λογική που το έχω αναπτύξει. πλέον που όλες οι σειριακές διαδικασίες δουλεύουν σωστά το πρόβλημα που προκύπτει είναι το εξής και ίσως είναι αρκετά σχετικό με την λογική που ανέπτυξα την συνάρτηση καταναλωτή.
Το πρόγραμμα ξεκινάει να δουλεύει και δουλεύει maximum 2 ώρες,
μέσα σε αυτές τις δυο ώρες η τιμή της μετοχής φτάνει από τα 100 στα 2000,
η Limit Buy ουρά δεν πέφτει κάτω από 1000 μετοχές μετά τα πρώτα 20 λεπτά
και έχει τάσεις να φλερτάρει με το όριο των 5000 εντολών μέχρι που γεμίζει, δεν υπάρχουν διαθέσιμες Market Sell ή limit Sell εντολές και εκεί τελειώνουν όλα.
Παρόμοια πορεία με την ουρά limit buy ακολουθούν παράλληλα και οι Stop Sell και Stop Limit Sell εντολές των οποίων ο όγκος ακολουθεί την αύξηση της τιμής της μετοχής (λογικόν μιας και ο έλεγχος είναι <=currentPrice)
Με λίγα λόγια δλδ το πρόγραμμα φτάνει σε αδιέξοδο μόνο του.

@time tripper: Στείλε mail να μάθουμε.

Όπως λέει στο pdf της εργασίας. Όλες οι συναλλαγές πρέπει να γίνονται με τέτοιο τρόπο έτσι ώστε, να οφελούνται περισότερρο
 οι συναλλαγές  market και όχι οι συναλλαγές limit. Πάνω σε αυτή τη λογική πρεπει να στειθεί το πρόβλημα.

Επίσης αν θυμάμαι καλά. Στο μάθημα είχε πει οτι η τιμή θα πρέπει να διακυμένεται γύρω απο μία τιμή και ουσιαστικά να υπάρχει σταθερότητα.

Αυτό αλλάζει πολλά... -_-

Θα επανεξετάσω την κάθε περίπτωση και θα 'ρθω να απλώσω καινούριο σεντόνι

παιδια μην μπερδευεστε, οπως λεει στο pdf πρωτα γινονται αν υπαρχουν limit-market ( ή market-limit), μετα market-market και μετα limit-limit.

Η προϋπόθεση για μια συναλλαγή limit-limit είναι να μην υπάρχουν συναλλαγές limit-market και LSprice1 < = LBprice1 σωστά;

Δηλαδή στην περίπτωση που έχουμε Market Buy - Limit Sell - Limit Buy
πρώτα ελέγχει αν η Limit Sell είναι κάτω του currentPrice αν είναι κάνει την συναλλαγή Market Buy - Limit Sell
αν δεν είναι επιχειρεί συναλλαγή limit Sell - Limit Buy με μοναδικό κριτήριο LSprice1< = LBprice1

Αν κατάλαβα σωστά τι λες, Ναι. Και εγώ έτσι το αντιμετώπισα  στο thread που ασχολείται με τις limit.

Να ρωτησω, εσεις το κανατε με ολα τα threads thread_create στην main και μετα χαμος με conditions ή σε καθε διεργασια δημιουργειτε καινουρια threads?

Παιδιά έχω προχωρήσει αρκετά την εργασία (σε φάση όπου ήμουν έτοιμος να προχωρήσω στην αναφορά), αλλά διαβάζωντας εδώ τα διάφορα posts έχω αρχίσει και έχω μερικές ανασφάλειες με τη δουλειά που έκανα.
Συγκεκριμένα το τι κάνει το εκάστοτε thread. Τα threads μου είναι τα ακόλουθα:

Prod : Όπως ήταν.
Cons : Καθώς βγαίνει μία εντολή από την αρχική Incoming Queue, μπαίνει σε μία από 8 Queues ανάλογα με το τι είδους εντολή είναι και το πόσο "ποθητή" είναι. Δεν πραγματοποιείται ακαριαίο transaction εδώ.
Stop : Δέχεται σήμα όταν αλλάζει η currentPrice, την κλειδώνει για να μην υπάρχουν ταυτόχρονα άλλα transactions και μεταφέρει αν και όπου γίνεται τις Stop εντολές όπου πρέπει. Έκανα 2 τέτοια thread και για μεγαλύτερη παραλληλοποίηση θα μπορούσαν να είναι 4.
Market : Τσεκάρει τις 2 πιο επιθυμητές Limit εντολές (μια Buy μια Sell) και το currentPrice και υπολογίζει πως θα μπορούσε να ευνοηθεί περισσότερο μία εντολή Market. Αν δε γίνεται transaction με Market μέσα, τότε ειδοποιεί την ...
Limit : Απλά παίρνει τις 2 πιο "ποθητές" Limit εντολές και αν το transaction είναι εφικτό, το πραγματοποιεί.
Write : Γράφει το αρχείο.

Τα άγχη μου είναι:
1) Δεν έχω transaction στο Cons. Καλό ή κακό ; Τι τρέχει με το ακαριαίο transaction ;
2) Δεν είναι και τόσο παράλληλος ο τρόπος που έχω τις Market και Limit.
3) H τιμή της μετοχής έχει μία μόνιμη φθίνουσα τάση. Θέλουμε όντως σταθερότητα ;

Ευχαριστώ εκ των προτέρων όποιον ξοδέψει χρόνο για να δει ό,τι έγραψα.

Προσωπικά τα έκανα με thread_create. Έχω την εντύπωση ότι η δημιουργία των threads είναι χρονοβόρα και δε θες να δημιουργείς ένα κάθε φορά για να κάνεις τη δουλειά σου. (Αν κατάλαβα καλά την ερώτηση.)
Εγώ ακολούθησα το μοτίβο του αέναου βρόχου, όπως τα 2 threads που ήταν έτοιμα. Βλέπουν συνεχώς αν μπορούν να κάνουν κάτι και ανάλογα περιμένουν ή προχωρούν στην επόμενη επανάληψη ώστε π.χ. να αλλάξει το φόρτο εργασίας τους. Το κλείσιμο των threads το κάνω με pthread_cancel.

Δεν θα σου πω με 100% βεβαιοτητα "Σιγουρα λαθος" αλλα θα σου πω οτι

κατι δεν ακουγεται καθολου καλα... 2 threads που κανουνε την ιδια δουλεια και μαλιστα mutex locks unlocks και σχετικα

κατι δεν ακουγεται καθολου καλα....

Για την ακριβεια δινει την εντυπωση οτι θα δημιουργει race condition ποιος θα διαβασει πρωτος το flag κλειδωματος.

Φυσικα καθως ειναι αναγνωση δεν πειραζει καθολου αυτο,απλα νομιζω ειναι περιττο

Κάποιες απορίες στην εκφώνηση...

Το πρόγραμμα παράγει ίχνος timestamp price volume orderid1 orderid2
Volume εννοεί πόσες μετοχές πουλήθηκαν? Επίσης, ordertype που αναφέρει πιο κάτω δεν υπάρχει καν στο ίχνος. Άρα γιατί το λέει?

Το σύστημα θα αποτελείται από ένα σύνολο νημάτων που εξυπηρετούν ξεχωριστά κάθε στάδιο και διπλή ουρά προτεραιότητας. Σας έχει δοθεί ο παραγωγός των εντολών συναλλαγών. Συστήνω να χρησιμοποιείτε ένα από ένα διαφορετικό νήμα για κάθε διεργασία ή ουρά και σήματα που να ειδοποιούν τα κατάλληλα νήματα όταν συμβαίνει κάτι.
Τι εννοεί στάδιο? Τι εννοεί διεργασία? Σίγουρα όχι unix processes.

Παραλληλα δεν εχεις παρει?

Νομίζω του ξέφυγε από την περσινή εργασία ή ξέχασε να το γράψει.


Με το στάδιο εννοεί ότι π.χ οι εντολές stop θα διαχειρίζονται από το νήμα stop_thread (δηλαδή θα κοιτάει για αλλαγές στην τιμή της μετοχής)
Αλλά όταν ικανοποιηθούν οι συνθήκες ενεργοποίησης τους και μετατραπούν σε market τις πασάρει στο market_thread. To ίδιο σκεπτικό ισχύει  και για τις stoplimit εντολές.

Το διεργασία του ξέφυγε, το πιο πιθανό εννοεί την κάθε εργασία που εκτελεί το κάθε thread.

---

Αυτό γίνεται αν υπάρχουν mutexes που προστατεύουν τις ουρές.

Είναι σύστημα ενός παραγωγού και 2 ή περισσότερων καταναλωτών.

Αυτό μπορεί να εφαρμοστεί θεωρητικά σε όλες τις ουρές, απλά δεν θα έχει σε όλες τις περιπτώσεις καλύτερες επιδώσεις σαν αποτέλεσμα.

Ναι... enlighten me.

Ευχαριστώ! Δε θέλω να πάρω ρίσκα :P

Λοιπόν αντιμετώπισα και εγώ αυτό το πρόβλημα. Ακόμα σκέφτομαι τι θα μπορούσα να κάνω για να το προσπεράσω.
Μάλλον η σωστή λύση είναι να κάτσουμε να σκεφτούμε κάποια περίπλοκη λύση για overflow management ;;

Σκέφτηκα όμως και τη μέθοδο της στρουθοκάμηλου. Όπως διάβασα και στο link που μας έδωσε στο pdf, λέει για τις εντολές Limit περίπου ότι είναι ένας καλός τρόπος να μην αγοράζεις όσο όσο, αλλά να βελτιστοποιείς τα κέρδη ή κόστη σου. Το downside είναι ότι μπορεί να χάσεις την ευκαιρία σου λόγω κάποιας άλλης πιο ελκυστικής limit εντολής. (ελπίζω να το κατάλαβα αυτό καλά και να μη το μετέφρασα απλά όπως ήθελα  :P)
Οπότε: σε μία πργματική μετοχή που η τιμή της ενδεχομένως μεταβάλλεται (παρότι η δικιά μας υποτίθεται ότι μένει σε σταθερή περίπου τιμή (και παρότι εμένα έχει καθοδική τάση  :P)), οι εντολές Limit που δεν είναι αρκετά ελκυστικές χάνουν την ευκαιρία τους και δεν εκτελούνται καθώς η τιμή αλλάζει. Δεν είναι λογικό ότι ο "παίχτης" θα ακύρωνε αυτή την εντολή σε τέτοια περίπτωση αντί να περιμένει η τιμή να επανέλθει μετά από πολλή ώρα;;
Με λίγα λόγια, όταν φουλάρει μία τέτοια queue και έχω αδιέξοδο διαγράφω από την queue τη λιγότερο ελκυστική εντολή. Ξέρω, δεν είναι σωστό και ντετερμινιστικό, αλλά είναι πολύ παράλογο;;

στην πραγματικοτητα το συστημα απο μονο του ακυρωνει τετοιες εντολες.. Αλλα δεν ξερω αν θελει κατι τετοιο στην εργασια.. απο τη στιγμη που οι εντολες ερχονται ισοπιθανα δεν θα επρεπε  να εξυπηρετουνται ολες χωρις να φουλαρουν οι ουρες?  :-\ :-\

και γω σκέφτηκα να σου πω την αλήθεια διάφορα σενάρια τότε, όπως να χρησιμοποιήσω της κεντρική queue σαν queue ασφαλείας,
σε φάση όταν φουλάρει η ουρα Limit Buy σταμάτα να μεταφέρεις τις Limit buy εντολές από την κεντρική queue στην limit buy queue μέχρι να μην είναι γεμάτη, βέβαια αυτό έδωσε έναν αέρα μιας παραπάνω ώρας (4+1 ώρες) στο πρόγραμμα όπου η τιμή της μετοχής πήγαινε κυριολεκτικά όπως να 'ναι και έτσι το παράτησα.

Η τιμή δεν πρέπει να μειώνεται ακαριαία, άντε να 'χει κάποια απόκλιση από τα 100 ευρώ αλλά όχι τίποτα σε φάση 200 ευρώ ή -10 ευρώ. Αυτό το πρόβλημα το αντιμετώπισα στην αρχή διότι δεν ήξερα πως δουλεύει το χρηματιστήριο και δεν ήμουν παρών στην αναπλήρωση του μαθήματος όταν ο καθηγητής έδινε τις διευκρινήσεις και έτσι η λύση δόθηκε κάποια στιγμή εδώ μέσα και όπως είπαμε για να 'ναι η τιμή σχετικά σταθερή πρέπει να εξυπηρετούνται οι Market εντολές πρωτίστως και δευτερευόντως οι limit.

Και όμως !! Αυτό που σκέφτηκα είναι το εξής: Οι εντολές έρχονται ισοπίθανα και τα price1, price2 δημιουργούνται τυχαία μέσα σε ένα συγκεκριμένο εύρος με μέσο το currentpriceΧ10. Αν όπως είπαμε η τιμή πρέπει να μένει σταθερή γύρω από κάποια τιμή, έστω 100.0, τότε π.χ. θα υπάρξουν εντολές Limit (και φυσικά Stop και Stop Limit) οι οποίες πχ θα βρίσκονται στο άκρο του εύρους απο την ΜΗ "ελκυστική" πλευρά του. Αυτές οι εντολές δε θα πραγματοποιηθούν ποτέ.
Σε ένα πραγματικό σύστημα ο "παίχτης" μάλλον δε θα έδινε μία τέτοια εντολή. Όπως φυσικά και μία Buy Stop Limit με price1 > price2. Τέσπα, έχω ξεφύγει.
Εν τέλει εγώ παιδιά σβήνω τις τελευταίες Limit, Stop  και Stop Limit των αντιστοιχων ουρών τους όταν είναι να μπεί κάποια καινούρια και είναι φούλ. Με έπεισες κιόλας με τα λόγια σου, ότι τα πραγματικά συστήματα κάνουν αυτό το πράμα.


Και εγώ σκέφτηκα να κάνω ή μία έξτρα queue ασφαλείας, ή ακόμα και αυτό που λες. Αλλά, αυτό θα έκανε την εκτέλεση του προγράμματος εντελώς μη ντετερμινιστική. (Δεν ξέρω πόσο το θέλουμε αυτό). Αυτό που θέλω να πω είναι ότι θα έβγαινε εντελώς διαφορετικό trace αν με αυτόν τον τρόπο εκτελούσες το πρόγραμμα με QUEUESIZE = 5000 και QUEUESIZE = 5050. Δεν ξέρω αν αυτό ειναι κακό, αλλά είναι κάτι το οποίο δε θα έκανα. Σβήσιμο και πάλι σβήσιμο  8))

Παιδια να ρωτησω κατι? Εμενα μου αργει πολυ να γινει transaction γιατι για να αλλαξει την τιμη πρεπει πρωτα να τελειωσουν 8 threads ( ενα για τις market - limit, eνα για τις limit - market, ενα για τις market - market, ενα για τις limit - limit και αλλα τεσσερα που ελεγχουν και μεταφερουν τις stop και stop limit στις αντιστοιχες market και limit ). Ομως αυτο ειναι τοσο αργο που φτανω να εχω πολλες sell market και limit market στην ουρα που θα επρεπε να εφευγαν ακαριαια! ΕΙναι δυνατον το wait να τρωει τοσο πολυ χρονο? Παιζει μηπως να φταιει και το οτι το τρεχω με 2πυρηνο μηχανημα (παει αργα σε σχεση με τον Διαδη) ή φταινε τα πολλα threads? Εσας οι χρονοι ειναι κανονικοι?

Ακομα κατι διευκρινιστικο:
Οι πρωταιρεοτητες δεν ειναι :
1) Limit  - market ή Market - Limit
2) Market - Market
3) Limit - Limit


εδιτ: το ελυσα το προβληματακι γιατι ειχα ενα κενο στη λογικη μου...

Χαίρομαι μιας και τώρα είδα το post σου. Τέσπα, οι προτεραιότητες είναι καλές και επίσης ένα μεγάλο like στα 4 threads που ασχολούνται με τις stop. Να κάτι που ξέχασα να κάνω παρότι το σκεφτόμουν...  :-\

Εν τέλει σε 2πύρηνο υπολογιστή έχει πιθανότητες να τρέξει ή θέλει Διάδη;

μετά απο 7 ώρες εκτελέστηκαν 1.110.000 παραγγελίες περίπου (bm-sm, bm-sl, bl-sm, bl-sl). Δηλαδη καπου μία εντολή ανα  22msec. Εσείς που περίπου βρίσκεστε?

Εγω ακομα το τρεχω....  :-\

Επρεπε να το παραδωσουμε μεχρι σημερα? Ποτε το ειπε αυτο ο Πιτς?

το είχε πει στο τελευταίο ή το προτελευταίο μάθημα αλλά νομίζω περισσότερο τυπικό ήταν.. και 3 4 μέρες μετά να την στείλεις δεν νομίζω να εχεί πρόβλημα.. Σε κάθε περίπτωση στείλτου ενα mail! Γενικά είναι αρκετά ελαστικός απότι έχει δείξει!

Νομιζω ειχε πει γενικα το Σεπτεμβρη, και υπεθεσα μεχρι ( βαρια - βαρια ) το περας της εξεταστικης.

εδιτ : παντως νταξει αυριο μαλλον θα το στειλω, δεν θα εχει προβλημα

Λοιπον εγω εκανα  4.574.018 συναλλαγες μεσα σε 8 ωρες οποτε ( αναλογικα ) σε 7 ωρες 4.002.265
Το μονο κακο ειναι οτι δεν ειναι σταθερη η τιμη αλλα εχει μια ( ελαχιστα ) καθοδικη πορεια που φτανει μεχρι την τιμη 90. Αυτο βεβαια στον δικο μου υπολογιστη, στο Διαδη εφτασε μεχρι τα 95.
Εσας σας βγαινει ευθεια?

Δε μας βγαίνει, ακόμα, κάτι με τις συναλλαγές παίζει και το ψάχνω
επίσης στο Διάδη δε μπορώ να μπω.
error connection refused on port 22 λέει
έψαξα το firewall του router του γείτονα, τα έχει όλα ανοιχτά
εγώ ίντερνετ δικό μου δεν έχω, ακόμα, κάνανε διακοπές οι τεχνικοί της HOL τον αύγουστο όλο

k emena eixe mikri ptwsi.. meta apo 7 wres eftase stathera sto 970.. i ptwsi arxise stis 2 wres apo t stigmi poy gemisan ta buffer sta BL kai SL kai arxisa na svinw.. isws ayto na epirreazei t diko m  :-\

metras kai tis allages katastasis twn stop k stop lim?

edit sorry gia ta greeklish..

οι αλλαγές κατάστασης δεν είναι συναλλαγές -_-

Οχι, μετραω μονο τις αλλαγες τιμων. Εμενα παλι ο Διαδης μου εδωσε καλυτερα αποτελεσματα, σταθεροποιηθηκε στο 95... περιεργα τα πραγματα. Παντως οταν κανω plot τα 1100000 μου βγαινει να σταθεροποιειται στα 97 οποτε πρεπει να εχουμε περιπου το ιδιο. 

Jimmako εχεις ξαναμπει με το λογαριασμο σου στο Διαδη? Γιατι καποια στιγμη ο Σισμανης μας ειχε πει για ενα προβλημα που καποιοι μπορει να αντιμετωπιζαν ( δε θυμαμαι ακριβως τι και πως ). Γενικα τωρα εσυ μπορεις να κανεις ssh? Περιεργο να μην μπαινει αφου λες οτι το router ( του γειτονα! ) ειναι ανοιχτο.  :-\

@tomshare3 και γενικά επειδή το έχω απορία.

όταν γεμίσουν τα Buffers των ουρών LS και LB μπορούμε να σβήσουμε όσες εντολές είναι στην LB κάτω του currentPrice και στην LS όσες είναι άνω του currentPrice? 

όχι ε;

@Time_Tripper
ο arashi Που ρθε από εδώ μια μέρα μες το καλοκαίρι κατάφερε και μπήκε
εγώ δεν έχω δικό μου account μπαίνω με άλλου ο οποίος μπαίνει κανονικά από το σπίτι του.
δίνω εντολή ssh username@diades.ee.auth.gr
και παίρνω "ssh: connect to host diades.ee.auth.gr port 22: Connection refused"

1) Εγω αυτο που κανω οταν γεμιζουν οι ουρες limit ειναι να διαγραφω την τελευταια μιας και για να γινει πρεπει πρωτα να γινουν 4999 πριν απο αυτη οποτε πρακτικα αυτοακυρωνεται. Εττσι βεβαια οταν γεμισει η ουρα παραμενει σχεδον συνεχεια γεμισμενη. Το να παρεις και να διαγραψεις αβερτα κουβερτα εντολες δεν μου φαινεται και πολυ αξιοκρατικο, ασε που αν διαγραψεις ολες οσες ειναι πανω ( ή κατω )  της τιμης ειναι σαν να ξεκινας τη διαδικασια απ την αρχη ακυρωνοντας οτι εχει γινει μεχρι τωρα ( πχ μπορει η τιμη σου να ειναι 100 και να εχεις 300 εντολες SL με τιμη 100.1, ε αμα εκεινη τη στιγμη αρχισουν να σου ερχονται καλες BL και BM ε θα γινει χαμος και θα τις ξεφορτωθεις ολες! :P Καλα τα παραλεω αλλα you get my point )

2) Στο Διαδη ολοι εχουν λογαριασμο (απ τη στιγμη που εχουν πανεπιστημιακο email ) οποτε εισαι σιγουρος οτι εσυ δεν εχεις?  :???:

Χρησιμοποιείς λάθος Port για να συνδεθείς

 

Επιβεβαιώνω...
Εγώ είχα στείλει mail και μου είχε πει μέχρι το τέλος της εξεταστικής

μαλλον οχι..  :-\ μπορει να αλλαξει μετα απο λιγο η τιμη και οι εντολες αυτες να επρεπε να εκτελεστουν κανονικα.. Και εγω την τελευταια στην ουρα εντολη σβηνω (και παλι δεν ειμαι σιγουρος οτι ετσι πρεπει να γινει!). Ισως με buffer 50.000 να μην χρειαζοταν αλλα δν παιζει να το ψαξω παραπανω!

Δεν και γω έτσι το κάνω πλέον, έχω φτιάξει 2 βασικές διαφορετικές στρατηγικές κατανάλωσης και έφτιαξα ένα κάρο σενάρια για την κάθε μια και πάλι οι buffers γεμίζουν.

πως ανεβάζουμε αρχεία στο Διάδη; έψαξα στο google και λέει scp
κάνω scp /home/mplampla/ESPX/Makefile αλλά δεν το παίρνει

καντο γραφικα απο λινουξ

connect to server μεσα απο τον "explorer "

και συμπληρωνεις τα υπολοιπα

πρεπει να δωσεις και την διευθυνση αποστολης.
πριν συνδεθεις με ssh κανε :
scp /home/mplampla/ESPX/Makefile username@diades.ee.auth.gr:.

(ή αν θες να στειλεις ολο τον φακελο -r /home/mplampla/ESPX/ )

Απο το μειλ του Σισμανη:


Προφανως δε χρειαζεσαι cygwin αν εισαι με linux.... :P

με τα αποτελεσματα τι παιζει?? μας ξεχασε??  :???:

κατσε καλε ακομα δεν μπηκε Οκτωβρης....  8)) ::)

Ποια αποτελέσματα ρε παιδιά, 2 οκτωβρίου είναι η διορία ;D

2 μηνες μετα κ ακομα τιποτα?!!  :D

Η συνολικη ενασχοληση μου με το μαθημα 8 ωρες οπως ειπε ο δασκαλος

και η συνακολουθη αποφαση να το αφησω στη μοιρα του

ηταν ΤΟΣΟ ΜΑ ΤΟΣΟ σωστη!

http://www.ultraslo.com/
για να περάσει η ώρα

βγήκαν οι βαθμολογίες στο e-thmmy