Kurs Qt – #8 – Wstęp do wielowątkowości w Qt

[Komentator]

W ósmej części kursu Qt zajmiemy się dokładniej tematem wielowątkowości. Wprowadzimy trochę nowej teorii i omówimy dobre praktyki. Napiszemy też prosty program, który pozwoli na wykorzystanie zdobytej wiedzy i przetestowanie omówionych zagadnień w praktyce.

UWAGA, to tylko wstęp! Dalsza część artykułu dostępna jest na blogu.

Przeczytaj całość »

Poniżej znajdują się komentarze powiązane z tym wpisem.

[Quasiprogmista]

Część,bardzo fajna seria artykułów chciałbym się zapytać czy planujecie może artykuł o ustawieniu łączności Arduino wi-fi przy pomocy QT ?

[Matthew11]

16 godzin temu, Quasiprogmista napisał:

Część,bardzo fajna seria artykułów chciałbym się zapytać czy planujecie może artykuł o ustawieniu łączności Arduino wi-fi przy pomocy QT ?

Plan zakłada artykuły z takiej tematyki, jednak na razie nie ma żadnych terminów. Między innymi wykorzystanie ESP8266/ESP32 i połączenie go z serwerem napisanym w Qt na kilka sposobów. Idea jest taka, żeby po serii można było zbudować podwaliny np. pod własny system inteligentnego domu. Kolejna cześć będzie małym wstępem do łączności za pomocą TCP/IP w lokalnej sieci, co powinno wystarczyć do ustanowienia połączenia między ESP a aplikacją.

@Quasiprogmista jak jesteś bardzo zainteresowany tematem to napisz do mnie a ja wskażę Ci miejsca gdzie szukać informacji.  

[Grzesiooo]

Dość dobry artykuł, jednak nie bez drobnych pomyłek:

1. W sekcji "Technologie wielowątkowe w Qt" napisane jest:
   "(...) klasa QThread. Klasa ta umożliwia utworzenie wątku, który istnieje od momentu jego uruchomienia aż do końca działania programu."
   Nie jest to cała prawda. Wątek utworzony przez klasę QThread przestaje istnieć, kiedy metoda QThread::run() zwróci kontrolę (return). W domyślnej implementacji jest tak, jak napisał Pan w artykule. Niemniej jednak, metoda QThread::run() jest wirtualna, więc można ją nadpisać (override). To drobny detal, jednak napisał Pan o nim pogrubioną czcionką, dlatego zwracam uwagę.
2. W sekcji "Przykład praktyczny" opisując nadpisywanie wirtualnego destruktora QObject używa Pan słowa konstruktor. Taki chochlik "drukarski" ;-)

Brakuje mi też przykładu automatycznego rozwiązania problemu użycia obiektów klas niejawnie współdzielonych (implicitly shared) w wielu wątkach poprzez przekazywanie ich mechanizmem sygnałów i slotów - zgodnie z sugestią dokumentacji Qt.

Poza tym, bardzo dobra robota! :-)

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[jugan1]

Małe pytanie:

Czy qDebug  w metodzie heavyCalculations klasy Worker ( dokładnie mówię o ) :

qDebug() << "Iteration" << i;

nie robi czasem "roboty"? Bez niego nadal byśmy mieli problem z płynnością GUI. Wg mnie on opóźnia szybkość emitowania sygnału progress, przez co główny wątek z GUI "nadąża".

Oczywiście nie mam na myśli tego, że to qDebug stoi za tym, że GUI jest cały czas aktywne. Po prostu nawet tworząc osobny wątek z różnymi obliczeniami to przy takiej szybkości słania sygnałów, główny wątek nie nadąża z odbieraniem ich i ustawianiem wartości w progressBarze ( pomimo, że nie wykonuje żadnych ciężkich obliczeń, które są wykonywane w tym nowym wątku), przez co on też zamula. Dopiero połączenie nowego wątku oraz qDebuqa sprawia, że wszystko wygląda ładnie.

Edytowano Czerwiec 25, 2021 przez jugan1

[Matthew11]

@jugan1 masz rację co do tego, że wykorzystanie qDebug() opóźnia emisję sygnału - jak każda operacja I/O w programie, a taką jest użycie qDebug(). Nie mniej to opóźnienie jest na tyle małe, że nie ma wpływu - należałoby to sprawdzić, ale pewnie doliczenie do 100'000 generuje "większe opóźnienie" niż wywołanie qDebug(). Możesz usunąć tę linię kodu i sprawdzić jak wtedy działa program - nie powinno być żadnej różnicy (przynajmniej na moim sprzęcie nie ma). 

To co tutaj "robi robotę" to wyłącznie to, że heavyCalculations() nie jest wykonywane w wątku GUI - dzięki czemu pętla for nie blokuje UI przez czas jej wykonywania - tylko w osobnym wątku, a jedyne co wtedy musi robić wątek GUI to obsłużyć sygnał i zaktualizować interfejs:

Ale owszem, jeśli będziemy bombardować wątek GUI dużą ilością sygnałów - wystarczy pozbyć się instrukcji if z heavyCalculations() i emitować sygnał co iterację pętli - to spowolni/zablokuje to działanie głównego wątku GUI, z tą różnicą, że wtedy na własne życzenie powodujemy taką sytuację.