RTOS (RTX OS) Πρόβλημα Mutex_Semaphore

[LOSTISLAND]

Γεια χαρά σε όλους, σκέφτηκα ότι οι μόνες διαφορές μεταξύ ένα mutex και σηματοφορέα είναι ο αριθμός (Δυνατότητα Semaphore) και αντιστροφή προτεραιότητας (Mutex Capability). Σήμερα, έχω συναντήσει κάτι παράξενο που ίσως σχετίζεται με την ικανότητα αντιστροφής προτεραιότητας ή κάτι άλλο. Να πάρει και την αποδέσμευση Mutex σηματοφορείς ή μεταξύ διαφορετικών καθηκόντων είναι σαφής, αλλά όταν τα χρησιμοποιούν σε ένα μόνο έργο, η συμπεριφορά τους είναι διαφορετική. Χρησιμοποιώντας σηματοφόρος το έργο είναι κλειδωμένη, αλλά χρησιμοποιώντας Mutex η εργασία δεν είναι κλειδωμένο. Φανταστείτε ότι υπάρχει ένα μόνο έργο που ονομάζεται APP_TestTask

 __task APP_TestTask άκυρη (void) {για (? ;) {Os_dly_wait (20)? Os_sem_wait (Sem_Test, 0xffff)? Os_sem_send (Sem_Test)? Os_sem_wait (Sem_Test, 0xffff)? Os_sem_wait ( Sem_Test, 0xffff)? Test_Function ()?}}

 _task APP_TestTask άκυρη (void) {για (? ;) {os_dly_wait (20)? os_mut_wait (Mut_Test, 0xffff)? os_mut_release (Mut_Test)? os_mut_wait ( Mut_Test, 0xffff)? os_mut_wait (Mut_Test, 0xffff)? Test_Function ()?}}

Είναι κάτι φυσικό ή σφάλμα; Χάρη στην προηγμένη

 

[willissilliw]

Πιστεύω ότι το πρόβλημα έγκειται με τις εγγενείς τους ορισμούς του σηματοφορέα και ένα mutex. Εάν χρησιμοποιείτε ένα έργο, τότε μπορούμε να υποθέσουμε ότι, εκτός από το σύστημα αδράνειας έργο, ότι "APP_TestTask" σας είναι η ύψιστη προτεραιότητα. Δεδομένου ότι ένα mutex ενσωματώνει αντιστροφή προτεραιότητα, και έχετε μόνο ένα έργο, το mutex πάντα θα πέσουν στο "APP_TestTask". Μια σηματοφόρος, όμως, προκαλεί προβλήματα από τη στιγμή που προσπαθούν να δώσουν τόσο μακριά και να πάρει το σηματοφόρος μέσα από ένα έργο? Ουσιαστικά, που προκαλεί το έργο να σβήσει. Δεν έχω χρησιμοποιήσει ποτέ ένα σηματοφορέα όταν έχω μόνο μία εργασία. Υπάρχει συγκεκριμένος λόγος για τον οποίο κάνετε αυτό; Regards, Willis