13.01.2008 21:33
[#1]
MUI i watki
Witam!
Zastanawia mnie ostatnio pewna kwestia. Otoz czy w programie pisanym pod MUI mozna zastosowac pewne mechanizmy znane z programowania współbieznego (chodzi mi po prostu o obsluge wątkow) ? Byc moze MUI posiada swoje wlasne mechanizmy realizujace wielowatkowosc programu ?
Podam moze prosty przyklad do czego jest mi to potrzebne. Mam taki sobie skromny interfejs graficzny MUI. Dwa przyciski - jeden nazywa sie START a drugi STOP. Do tego mam pasek stanu. Po nacisniecu na przycisk START uruchamiana jest petelka "for", ktora zwieksza pasek stanu (ale z pewnym opoznieniem, tak aby wypelnianie sie paska bylo widoczne dla uzytkownika). Niech ta petelka liczy sobie od 0 do 1000 iteracji. Maksymalna pojemnosc paska stanu to tez 1000.
I co chcialbym tutaj osiagnac? A no to, ze po kliknieciu na przycisk STOP np. przy 150 iteracji, petla "for" sie zatrzymuje. Z kolei po ponownym nacisnieciu przycisku START, petla jest jakby "wznawiana" od iteracji 151 i kreci sie dalej do 1000 (lub do kolejnego "zawieszenia" przez STOP). Czy taka operacja jest w MUI mozliwa? Jak najlepiej sie do tego zabrac ?
Za wszelkie uwagi bylbym very wdzieczny
Pozdrawiam
MarX
Zastanawia mnie ostatnio pewna kwestia. Otoz czy w programie pisanym pod MUI mozna zastosowac pewne mechanizmy znane z programowania współbieznego (chodzi mi po prostu o obsluge wątkow) ? Byc moze MUI posiada swoje wlasne mechanizmy realizujace wielowatkowosc programu ?
Podam moze prosty przyklad do czego jest mi to potrzebne. Mam taki sobie skromny interfejs graficzny MUI. Dwa przyciski - jeden nazywa sie START a drugi STOP. Do tego mam pasek stanu. Po nacisniecu na przycisk START uruchamiana jest petelka "for", ktora zwieksza pasek stanu (ale z pewnym opoznieniem, tak aby wypelnianie sie paska bylo widoczne dla uzytkownika). Niech ta petelka liczy sobie od 0 do 1000 iteracji. Maksymalna pojemnosc paska stanu to tez 1000.
I co chcialbym tutaj osiagnac? A no to, ze po kliknieciu na przycisk STOP np. przy 150 iteracji, petla "for" sie zatrzymuje. Z kolei po ponownym nacisnieciu przycisku START, petla jest jakby "wznawiana" od iteracji 151 i kreci sie dalej do 1000 (lub do kolejnego "zawieszenia" przez STOP). Czy taka operacja jest w MUI mozliwa? Jak najlepiej sie do tego zabrac ?
Za wszelkie uwagi bylbym very wdzieczny
Pozdrawiam
MarX
13.01.2008 22:01
[#3]
Re: MUI i watki
@MarX, post #1
Zastanawia mnie ostatnio pewna kwestia. Otoz czy w programie pisanym pod MUI mozna zastosowac pewne mechanizmy znane z programowania współbieznego (chodzi mi po prostu o obsluge wątkow)?
Oczywiście, że można.
Byc moze MUI posiada swoje wlasne mechanizmy realizujace wielowatkowosc programu?
MUI 3 nie, MUI 4 tak.
I co chcialbym tutaj osiagnac? A no to, ze po kliknieciu na przycisk STOP np. przy 150 iteracji, petla "for" sie zatrzymuje. Z kolei po ponownym nacisnieciu przycisku START, petla jest jakby "wznawiana" od iteracji 151 i kreci sie dalej do 1000 (lub do kolejnego "zawieszenia" przez STOP). Czy taka operacja jest w MUI mozliwa? Jak najlepiej sie do tego zabrac ?
Jeżeli to jest cały efekt jaki mamy osiągnąć, to wielowątkowość nie jest do niczego potrzebna. Jeżeli to natomiast tylko przykładzik ilustrujący jakieś poważniejsze zagadnienie, to mam pytanie, co tak naprawdę jest do zrobienia?
Oczywiście, że można.
Byc moze MUI posiada swoje wlasne mechanizmy realizujace wielowatkowosc programu?
MUI 3 nie, MUI 4 tak.
I co chcialbym tutaj osiagnac? A no to, ze po kliknieciu na przycisk STOP np. przy 150 iteracji, petla "for" sie zatrzymuje. Z kolei po ponownym nacisnieciu przycisku START, petla jest jakby "wznawiana" od iteracji 151 i kreci sie dalej do 1000 (lub do kolejnego "zawieszenia" przez STOP). Czy taka operacja jest w MUI mozliwa? Jak najlepiej sie do tego zabrac ?
Jeżeli to jest cały efekt jaki mamy osiągnąć, to wielowątkowość nie jest do niczego potrzebna. Jeżeli to natomiast tylko przykładzik ilustrujący jakieś poważniejsze zagadnienie, to mam pytanie, co tak naprawdę jest do zrobienia?
14.01.2008 15:34
[#5]
Re: MUI i watki
@Grzegorz Kraszewski, post #3
Witam!
Zagadnienie rzeczywiście jest "troche" poważniejsze. Otóż musze napisać na zaliczenie przedmiotu sterownik rozmyty pewnego urządzenia. Chodzi o to, że mając pewne dane wejściowe (np. pobierane jeden raz z dajmy na to trzech suwaków) dokonuje ich przetworzenia w petli (teoretycznie nieskonczonej). Wyniki są z kolei danymi wejściowymi dla kolejnego obrotu petli. Chciałbym aby była możliwość reakcji na suwaki w czasie działania tej petli. Np. gdy przesune suwak, to liczba którą wskarze suwakiem była daną wejsciową w kolejnej iteracji, ciągle działającej petli for. Chciałbym mieć też możliwość zatrzymania i wznowienia petli od iteracji na której poprzednio sie zatrzymałem (czyli to o czym pisalem w poprzednim poście).
I tak mysle jak do tego sie zabrać. Jakich metod użyć? MinisterQ wspomniał o MUIM_Application_PushMethod, czy to jest dobry trop?
Pozdrawiam i dzieki za odpowiedź!
MarX
p.s. program pisze na klasycznej Amidze, korzystam z MUI 3.8
Zagadnienie rzeczywiście jest "troche" poważniejsze. Otóż musze napisać na zaliczenie przedmiotu sterownik rozmyty pewnego urządzenia. Chodzi o to, że mając pewne dane wejściowe (np. pobierane jeden raz z dajmy na to trzech suwaków) dokonuje ich przetworzenia w petli (teoretycznie nieskonczonej). Wyniki są z kolei danymi wejściowymi dla kolejnego obrotu petli. Chciałbym aby była możliwość reakcji na suwaki w czasie działania tej petli. Np. gdy przesune suwak, to liczba którą wskarze suwakiem była daną wejsciową w kolejnej iteracji, ciągle działającej petli for. Chciałbym mieć też możliwość zatrzymania i wznowienia petli od iteracji na której poprzednio sie zatrzymałem (czyli to o czym pisalem w poprzednim poście).
I tak mysle jak do tego sie zabrać. Jakich metod użyć? MinisterQ wspomniał o MUIM_Application_PushMethod, czy to jest dobry trop?
Pozdrawiam i dzieki za odpowiedź!
MarX
p.s. program pisze na klasycznej Amidze, korzystam z MUI 3.8
14.01.2008 16:41
[#6]
Re: MUI i watki
@MarX, post #5
W tym przypadku MUIM_Application_PushMethod Ci się nie przyda, z racji tego że za pomocą tej metody nie można odczytywać wartości z obiektów. No i generalnie rzecz biorąc odczyt wartości z obiektów z innego wątku ogólnie pod MUI 3.8 jest "nielegalny".
Najprościej będzie jak użyjesz hooka który będzie odczytywać wartości z suwaków, i zapisywać te wartości w jakichś zmiennych globalnych, albo w jakiejś strukturze, do których będzie miał dostęp również wątek z pętlą for().
Ewentualnie możesz się pobawić w systemowe messages z exec.library, które zrobią to samo w "ładny" sposób, ale generalnie będzie to IMHO przerost formy.
Najprościej będzie jak użyjesz hooka który będzie odczytywać wartości z suwaków, i zapisywać te wartości w jakichś zmiennych globalnych, albo w jakiejś strukturze, do których będzie miał dostęp również wątek z pętlą for().
Ewentualnie możesz się pobawić w systemowe messages z exec.library, które zrobią to samo w "ładny" sposób, ale generalnie będzie to IMHO przerost formy.
14.01.2008 18:47
[#8]
Re: MUI i watki
@MarX, post #5
W tym zastosowaniu wielowątkowość nie jest potrzebna. Wszystko co trzeba zrobić, to subklasować klasę aplikacji i zaimplementować MUIM_HandleInput. Przy dodawaniu InputHandlera używamy flagi MUIIHNF_TIMER i podajemy czas w mikrosekundach (jest to opisane w autodocach MUI, klasa Application, metoda MUIM_Application_AddInputHandler()). To powoduje, że nasza MUIM_HandleInput jest wywoływana w regularnych odstępach czasu niejako automatycznie. W tej metodzie wykonujemy iteracje pętli. Natomiast najbardziej eleganckim rozwiązaniem problemu przekazania pozycji suwaków do pętli jest napisanie własnej metody OM_SET dla naszej podklasy aplikacji. Metoda ta po prostu będzie zapisywała pozycje suwaków w polach danych obiektu, skąd przy każdej iteracji wewnątrz MUIM_HandleInput będziemy je sobie odczytywać.
Dzięki temu nie będziemy musieli niczym zanieczyszczać pętli głównej programu, obsłużenie zmiany położenia suwaków w czasie obliczeń wymaga jedynie napisania jednej notyfikacji na każdy suwak.
Dzięki temu nie będziemy musieli niczym zanieczyszczać pętli głównej programu, obsłużenie zmiany położenia suwaków w czasie obliczeń wymaga jedynie napisania jednej notyfikacji na każdy suwak.
14.01.2008 19:57
[#9]
Re: MUI i watki
@Grzegorz Kraszewski, post #8
> W tym zastosowaniu wielowątkowość nie jest potrzebna.
A mi się wydaje, że jak najbardziej jest potrzebna. GUI chodzi na jednym wątku (procesie) i zapisuje do globalnej strukturki wszystkie parametry, a drugi wątek (proces) zajmuje się tylko i wyłącznie liczeniem. Takie coś daje największą przejrzystość kodu. Wszelkie inne rozwiązania tworzą niestety straszne potworki i akrobacje w kodzie (najlepszym przykładem jest niestety mój SFSDoctor).
A mi się wydaje, że jak najbardziej jest potrzebna. GUI chodzi na jednym wątku (procesie) i zapisuje do globalnej strukturki wszystkie parametry, a drugi wątek (proces) zajmuje się tylko i wyłącznie liczeniem. Takie coś daje największą przejrzystość kodu. Wszelkie inne rozwiązania tworzą niestety straszne potworki i akrobacje w kodzie (najlepszym przykładem jest niestety mój SFSDoctor).
14.01.2008 23:00
[#10]
Re: MUI i watki
@Grzegorz Kraszewski, post #8
Witam!
Pomysł z hookiem jest zdecydowanie najprostszy i chyba od niego zaczne. Chociaż przyznam że bardzo zainteresowała mnie kwestia użycia MUIM_HandleInput. Oczywiście wszystko wyjdzie w praniu i w czasie programowania. Póki co zatapiam sie w autodocach i zaczynam coś powoli rzeźbić. Dzieki za naprowadzenie na konkretne metody.
Pozdrawiam!
MarX
p.s. Rzooku, przy pomyślnych wiatrach skoncze studia na UMCS dopiero za pół roku ;)
Pomysł z hookiem jest zdecydowanie najprostszy i chyba od niego zaczne. Chociaż przyznam że bardzo zainteresowała mnie kwestia użycia MUIM_HandleInput. Oczywiście wszystko wyjdzie w praniu i w czasie programowania. Póki co zatapiam sie w autodocach i zaczynam coś powoli rzeźbić. Dzieki za naprowadzenie na konkretne metody.
Pozdrawiam!
MarX
p.s. Rzooku, przy pomyślnych wiatrach skoncze studia na UMCS dopiero za pół roku ;)
15.01.2008 10:33
[#12]
Re: MUI i watki
@Marek Szyprowski, post #9
GUI chodzi na jednym wątku (procesie) i zapisuje do globalnej strukturki wszystkie parametry, a drugi wątek (proces) zajmuje się tylko i wyłącznie liczeniem. Takie coś daje największą przejrzystość kodu.
To biorąc pod uwagę, że oba procesy czytają i zapisują tę strukturę, zaproponowałbyś przynajmniej jej zabezpieczenie semaforem... Całkowicie się nie zgadzam, że odpalenie drugiego procesu daje tu cokolwiek w przejrzystości kodu. Balet ze zmiennymi globalnymi to bardzo dobry sposób na zapewnienie sobie trudnych do wyłapania błędów. Uważam, że subklasowanie klasy Application i napisanie tam raptem 3 metod + do tego parę notyfikacji jest bardziej przejrzyste. Skoro MUI jest toolkitem obiektowym, to żeby zachować przejrzystość, trzeba się trzymać tej obiektowości...
To biorąc pod uwagę, że oba procesy czytają i zapisują tę strukturę, zaproponowałbyś przynajmniej jej zabezpieczenie semaforem... Całkowicie się nie zgadzam, że odpalenie drugiego procesu daje tu cokolwiek w przejrzystości kodu. Balet ze zmiennymi globalnymi to bardzo dobry sposób na zapewnienie sobie trudnych do wyłapania błędów. Uważam, że subklasowanie klasy Application i napisanie tam raptem 3 metod + do tego parę notyfikacji jest bardziej przejrzyste. Skoro MUI jest toolkitem obiektowym, to żeby zachować przejrzystość, trzeba się trzymać tej obiektowości...
15.01.2008 11:26
[#13]
Re: MUI i watki
@Grzegorz Kraszewski, post #12
To biorąc pod uwagę, że oba procesy czytają i zapisują tę strukturę, zaproponowałbyś przynajmniej jej zabezpieczenie semaforem...
W przypadku gdy drugi proces jedynie ODCZYTUJE te dane, to po co?
Przecież wyraźnie jest napisane że wartości pochodzą z suwaków które użytkownik będzie sobie ustawiać. Po co ten drugi proces miałby cokolwiek w tych wartościach mieszać?
Uważam, że subklasowanie klasy Application i napisanie tam raptem 3 metod + do tego parę notyfikacji jest bardziej przejrzyste.
Nie jest. To nie jest takie samo subklasowanie jak w przypadku c++, czy innych języków obiektowych, i trudno tu mówić o przejrzystości, zwłaszcza w przypadku osoby początkującej stawiającej pierwsze kroki z MUI, czy BOOPSI.
Dodatkowo nie wiem czy inputhandler nie będzie źle wpływać na wydajność owego "podprocesu" z pętlą - to w końcu nie to samo co osobny proces, który wywoływany jest bezpośrednio przez kernel. No i ostatecznie - jeśli pętla w której działa coś czasochłonnego będzie trwać zbyt długo, spowoduje to dość przykre w takich przypadkach w MUI (przy)blokowanie działania GUI, przynajmniej do czasu zakończenia tej operacji.
W przypadku gdy drugi proces jedynie ODCZYTUJE te dane, to po co?
Przecież wyraźnie jest napisane że wartości pochodzą z suwaków które użytkownik będzie sobie ustawiać. Po co ten drugi proces miałby cokolwiek w tych wartościach mieszać?
Uważam, że subklasowanie klasy Application i napisanie tam raptem 3 metod + do tego parę notyfikacji jest bardziej przejrzyste.
Nie jest. To nie jest takie samo subklasowanie jak w przypadku c++, czy innych języków obiektowych, i trudno tu mówić o przejrzystości, zwłaszcza w przypadku osoby początkującej stawiającej pierwsze kroki z MUI, czy BOOPSI.
Dodatkowo nie wiem czy inputhandler nie będzie źle wpływać na wydajność owego "podprocesu" z pętlą - to w końcu nie to samo co osobny proces, który wywoływany jest bezpośrednio przez kernel. No i ostatecznie - jeśli pętla w której działa coś czasochłonnego będzie trwać zbyt długo, spowoduje to dość przykre w takich przypadkach w MUI (przy)blokowanie działania GUI, przynajmniej do czasu zakończenia tej operacji.
15.01.2008 14:14
[#15]
Re: MUI i watki
@Grzegorz Kraszewski, post #12
Grzegorz Kraszewski napisał(a):
> To biorąc pod uwagę, że oba procesy czytają i zapisują tę
> strukturę, zaproponowałbyś przynajmniej jej zabezpieczenie
> semaforem...
To mi się wydawało na tyle oczywiste (że semafor powinien być), że nie pisałem o tym.
> Całkowicie się nie zgadzam, że odpalenie drugiego
> procesu daje tu cokolwiek w przejrzystości kodu.
Daje dokładnie tyle, że jak kiedyś będzie potrzeba przeniesienia tego programu pod inny toolkit/system to tam zrobi się to dokładnie tak samo - 2 wątki/procesy i problem z głowy. Wszelkie zakopywanie głównego kodu gdzieś głęboko w "obiekty" MUI jest ślepą uliczką moim zdaniem. Do tego skoro jest to projekt na uczelnię to taki kod zapewne chciałyby oglądać jeszcze innego osoby (choćby oceniający) - więc dobrze jest to podzielić go tak, aby był czytelny.
> To biorąc pod uwagę, że oba procesy czytają i zapisują tę
> strukturę, zaproponowałbyś przynajmniej jej zabezpieczenie
> semaforem...
To mi się wydawało na tyle oczywiste (że semafor powinien być), że nie pisałem o tym.
> Całkowicie się nie zgadzam, że odpalenie drugiego
> procesu daje tu cokolwiek w przejrzystości kodu.
Daje dokładnie tyle, że jak kiedyś będzie potrzeba przeniesienia tego programu pod inny toolkit/system to tam zrobi się to dokładnie tak samo - 2 wątki/procesy i problem z głowy. Wszelkie zakopywanie głównego kodu gdzieś głęboko w "obiekty" MUI jest ślepą uliczką moim zdaniem. Do tego skoro jest to projekt na uczelnię to taki kod zapewne chciałyby oglądać jeszcze innego osoby (choćby oceniający) - więc dobrze jest to podzielić go tak, aby był czytelny.
15.01.2008 14:14
[#16]
Re: MUI i watki
@MinisterQ, post #13
[/i]W przypadku gdy drugi proces jedynie ODCZYTUJE te dane, to po co?[/i]
Ja zrozumiałem, że oba procesy odczytują i zapisują. Proces obliczeniowy przecież przechowuje stan obliczeń między iteracjami gdzieś, chyba że zrobisz dwa zestawy zmiennych, jeden dla obu procesów a drugi dla obliczeniowego (wtedy mogą to być nawet zmienne lokalne). Ale jeżeli nawet jeden z procesów tylko czyta, to jak myślisz, po co istnieje funkcja ObtainSemaphoreShared()? Zresztą Kiero Ci wyjaśnił...
Ja zrozumiałem, że oba procesy odczytują i zapisują. Proces obliczeniowy przecież przechowuje stan obliczeń między iteracjami gdzieś, chyba że zrobisz dwa zestawy zmiennych, jeden dla obu procesów a drugi dla obliczeniowego (wtedy mogą to być nawet zmienne lokalne). Ale jeżeli nawet jeden z procesów tylko czyta, to jak myślisz, po co istnieje funkcja ObtainSemaphoreShared()? Zresztą Kiero Ci wyjaśnił...
15.01.2008 14:29
[#17]
Re: MUI i watki
@Grzegorz Kraszewski, post #16
Okej, niech wam będzie ten semafor przy manipulacji jedną wartością za pomocą suwaka/przycisku. ;) Co do reszty zdania nie zmieniam. ;)
Przyciski zapisujące swoje stany gdzieś w zmiennych typu BOOL, a wątek który na to reaguje zwiększa/zmniejsza pasek stanu za pomocą MUIM_Application_PushMethod, i szafa gra. Do tego hook który ma notyfikację na suwaki, i ustala wartości iteracji. Obsługę całego GUI można w zasadzie zrobić na jednym hooku.
A nie jakieś cudowanie z subklasowaniem i inputhandlerami.
Przyciski zapisujące swoje stany gdzieś w zmiennych typu BOOL, a wątek który na to reaguje zwiększa/zmniejsza pasek stanu za pomocą MUIM_Application_PushMethod, i szafa gra. Do tego hook który ma notyfikację na suwaki, i ustala wartości iteracji. Obsługę całego GUI można w zasadzie zrobić na jednym hooku.
A nie jakieś cudowanie z subklasowaniem i inputhandlerami.
15.01.2008 14:32
[#18]
Re: MUI i watki
@kiero, post #14
zeby wyeliminowac scenariusz kiedy czesc danych zostala juz zaktualizowana, a czesc jeszcze nie. oczywiscie jezeli takie cos moze sie zdazyc.
W przypadku suwaków, czy przycisków, gdy użytkownik manipuluje w danej chwili tylko jedną wartością, to raczej bardzo mało prawdopodobne. ;)
Co najwyżej dla świętego spokoju.
W przypadku suwaków, czy przycisków, gdy użytkownik manipuluje w danej chwili tylko jedną wartością, to raczej bardzo mało prawdopodobne. ;)
Co najwyżej dla świętego spokoju.