Czego nauczyłeś się z projektu, który prawie / właściwie zawiódł z powodu złej wielowątkowości?
Czasami framework narzuca pewien model wątkowania, który sprawia, że trudniej jest uzyskać porządek o rząd wielkości.
Jeśli chodzi o mnie, muszę jeszcze wyjść z ostatniej porażki i uważam, że lepiej dla mnie nie pracować nad niczym, co ma związek z wielowątkowością w tych ramach.
Przekonałem się, że byłem dobry w problemach z wielowątkowością, które mają proste rozwidlenie / łączenie i gdzie dane przemieszczają się tylko w jednym kierunku (podczas gdy sygnały mogą przemieszczać się w kierunku kołowym).
Nie jestem w stanie obsłużyć GUI, w którym część pracy można wykonać tylko na ściśle serializowanym wątku („główny wątek”), a inną pracę można wykonać tylko na dowolnym wątku oprócz głównego wątku („wątki robocze”), oraz gdzie dane i komunikaty muszą przemieszczać się we wszystkich kierunkach między N składowymi (w pełni połączony wykres).
W momencie, gdy zostawiłem ten projekt na inny, wszędzie występowały problemy z impasem. Słyszałem, że 2-3 miesiące później kilku innym programistom udało się naprawić wszystkie problemy z impasem do tego stopnia, że można je wysłać do klientów. Nigdy nie udało mi się znaleźć tej brakującej wiedzy, której mi brakuje.
Coś w projekcie: liczba identyfikatorów wiadomości (wartości całkowite opisujące znaczenie zdarzenia, które można wysłać do kolejki komunikatów innego obiektu, niezależnie od wątków) wynosi kilka tysięcy. Unikalne ciągi (wiadomości użytkownika) również mają około tysiąca.
Dodany
Najlepszą analogią, jaką otrzymałem od innego zespołu (niezwiązaną z moimi wcześniejszymi lub obecnymi projektami), było „umieszczenie danych w bazie danych”. („Baza danych” odnosząca się do centralizacji i aktualizacji atomowych.) W graficznym interfejsie użytkownika podzielonym na wiele widoków, wszystkie działające w tym samym „głównym wątku”, a wszystkie operacje podnoszenia ciężarów innych niż GUI są wykonywane w poszczególnych wątkach roboczych, dane aplikacji powinny być przechowywane w jednym pliku, który działa jak baza danych, i pozwól „bazie danych” obsłużyć wszystkie „aktualizacje atomowe” obejmujące nietrywialne zależności danych. Wszystkie pozostałe części GUI obsługują tylko rysowanie ekranu i nic więcej. Części interfejsu użytkownika mogą buforować pliki, a użytkownik nie zauważy, czy są ułamkowe przez ułamek sekundy, jeśli są odpowiednio zaprojektowane. Ta „baza danych” jest również znana jako „dokument” w architekturze Document-View. Niestety - nie, moja aplikacja faktycznie przechowuje wszystkie dane w widokach. Nie wiem, dlaczego tak było.
Współtwórcy:
(autorzy nie muszą używać prawdziwych / osobistych przykładów. Mile widziane są również wnioski z niepotwierdzonych przykładów, jeśli sam ocenisz je jako wiarygodne).