Witam
Chcialbym wykozystywac komponenty wewnatrz watku ale, w watkach chyba nie ma obslugi zdazen...
czy mozna w jakis latwy i przyjemny sposob zapewnic ten mechanizm?
0
0
Najlatwiej to za pomoca zdarzen z komponentow ustawiac jakies zmienne sterujace watkiem. Pamietaj o zabezpieczeniu tych zmiennych przed wielodostepem.
0
no wlasnie pamietam i powoli mnie to zaczyna przerazac:D
jest takie cos jak TMultiReadExclusiveWriteSynchronizer
czy powinienem uzywac tego do pojedynczych komend czy moge
do calych procedur (albo jeszcze wiekszych kawalkow programu)??
- ok na to juz sobie * no i zastanawiam sie co bedzie jesli w czasie czytania kawalka pamieci
- odpowiedzialem * ktos zablokuje ten kawalek w celu dokonania zapisu?
--dopisane--
Czy istnieja mechanizmy, ktore umozliwilyby zwrocenie 'wartosci domyslnej' albo wykonanie innych czynnosci w przypadku zablokowania dostepu do pamieci?
Z tego co rozumiem sekcje krytyczne (gdy sa 'zajete') wstrzymuja dzialanie watku az do momentu kiedy dana sekcja krytyczna zostanie zwolniona przez zajmujacy ja watek. Chcialbym uniknac takich przestojow.
0
to użyj muteksów/semaforów, możesz tam podać timeout, a potem sprawdzić, czy nastąpił, czy też wątek doczekał się swojej kolejki.
nie możesz zablokować pamięci ani na czas zapisu, ani odczytu (chyba, że celowo będziesz manipulował uprawnieniami), możesz tylko programowo synchronizować dostęp do niej. jeśli synchronizujesz dostęp do pamięci, to nie ma znaczenia, czy to zapis czy odczyt, i tak wykona się po zakończeniu wszystkich innych operacji (tylko jeden wątek naraz może być wewnątrz sekcji krytycznej czy muteksu). jeśli nie będziesz synchronizować dostępu, to odczytane dane częściowo mogą zawierać nowe dane, a częściowo stare - i właśnie dlatego i tylko dlatego musisz wielowątkowy dostęp do zmiennych synchronizować.
0
ŁF napisał(a)
to użyj muteksów/semaforów, możesz tam podać timeout, a potem sprawdzić, czy nastąpił, czy też wątek doczekał się swojej kolejki.
Po co to tak komplikowac?
TMultiReadExclusiveWriteSynchronizer - mozesz go uzyc dla zabezpieczania metod __property twoich obiektow. Metod BeginRead(), EndRead() uzywaz przy odczycie property, metod BeginWrite() EndWrite() przy ustawianiu property. Pamietaj ze gdy chcesz uzyc rejestrow __property w swojej procedurze watku to tez musza byc obudowane przez BeginRead() EndRead() (najlepiej zrobic sobie kopie wszystkich wlasciwosci gdzies na poczatku algorytmu)
TCriticalSection - uzywasz jego metod Lock() Unlock() do zabezpieczenia miejsc w kodzie w ktorych w danym momencie moze sie poruszac tylko jeden watek, mozna go takze uzyc do __property ale multisynchronizer jest wydajniejszy w tym przypadku
TEvent - tego uzyjesz kiedy bedziesz chcial zeby jeden watek czekal na wykonanie drugiego, cos czekalo na zakonczenie wszystkich watkow itd. itp.
Mutexy i semafory w tym przypadku to jest wytaczanie dziala w celu upolowania komara.
A tak miedzy bugiem a prawda to w czasach procesorow wielordzeniowych aplikacje wielowatkowe powinno sie pisac z uzyciem czegos takiego http://threadingbuildingblocks.org/
Johny_Morfina napisał(a)
Czy istnieja mechanizmy, ktore umozliwilyby zwrocenie 'wartosci domyslnej' albo wykonanie innych czynnosci w przypadku zablokowania dostepu do pamieci?
Z tego co rozumiem sekcje krytyczne (gdy sa 'zajete') wstrzymuja dzialanie watku az do momentu kiedy dana sekcja krytyczna zostanie zwolniona przez zajmujacy ja watek. Chcialbym uniknac takich przestojow.
Ja pisalem wczesniej cala wymiana danych odbywa sie za pomoca __property, metody __property sa zebezbieczone przed wielodostepem np.
void TMultiThreadSafeObject::SetA(int A)
{
FpMultiRWSync->BeginWrite();
FA = A;
FpMultiRWSync->EndWrite();
}
int TMultiThreadSafeObject::GetA(void)
{
int Result;
FpMultiRWSync->BeginRead();
Result = FA;
FpMultiRWSync->EndRead();
return Result;
}
I teraz jak w watku chcesz cos zrobic z FA to zaleznie od tego czy bedziesz czytal czy pisal do FA znowu ta operacje obudowujesz Begin... End... (Najwydajniej jest zrobic kopie gdzies na poczatku petli watku)
Jesli chodzi o 'przestoje' to najczesciej spowodowane one sa ze gdzies brakuje unlock po lock albo cos w ten desen.
0
EgonOlsen napisał(a)
ŁF napisał(a)
to użyj muteksów/semaforów, możesz tam podać timeout, a potem sprawdzić, czy nastąpił, czy też wątek doczekał się swojej kolejki.
Po co to tak komplikowac?
TMultiReadExclusiveWriteSynchronizer (...)
masz gdzieś w tym obiekcie możliwość podania timeoutu? bo nie widzę tam czegoś takiego - przeczytałeś uważnie pytanie?
0
ŁF napisał(a)
EgonOlsen napisał(a)
ŁF napisał(a)
to użyj muteksów/semaforów, możesz tam podać timeout, a potem sprawdzić, czy nastąpił, czy też wątek doczekał się swojej kolejki.
Po co to tak komplikowac?
TMultiReadExclusiveWriteSynchronizer (...)
masz gdzieś w tym obiekcie możliwość podania timeoutu? bo nie widzę tam czegoś takiego - przeczytałeś uważnie pytanie?
Timeout przy odczycie/zapisie property? To sa czasy liczone w nanosekundach jesli nie mniej. Raczej bardziej przejmowalbym sie deadlockami niz timeoutami przy takich operacjach. <ort>poza tym </ort>nie widze tutaj nigdzie pytania o timeouty.
0
EgonOlsen napisał(a)
Timeout przy odczycie/zapisie property? To sa czasy liczone w nanosekundach jesli nie mniej. Raczej bardziej przejmowalbym sie deadlockami niz timeoutami przy takich operacjach. <ort>poza tym</ort> nie widze tutaj nigdzie pytania o timeouty.
-
nikt nie powiedział, ile trwa synchronizowana operacja, skąd wiesz, że nie kilkaset milisekund?
Johny_Morfina napisał(a)
Czy istnieja mechanizmy, ktore umozliwilyby zwrocenie 'wartosci domyslnej' albo wykonanie innych czynnosci w przypadku zablokowania dostepu do pamieci?
0
czasem zmienna dzielona miedzy watkami jest lista obiektow i w jednej procedurze
odwoluje sie do tej listy kilka razy
(np biore pierwszy element,
cos z nim robie,
kasuje z poczatku i dodaje na koniec)
wiec <ort>z tad</ort> pytanie:
Johny_Morfina napisał(a)
jest takie cos jak TMultiReadExclusiveWriteSynchronizer
czy powinienem uzywac tego do pojedynczych komend czy moge
do calych procedur (albo jeszcze wiekszych kawalkow programu)??
moglbym w takiej procedurze kazde odwolanie do listy i jej obiektow oblozyc oddzielna sekcja krytyczna,
albo calal procdure do niej wpakowac. Jesli zrobie jedna sekcje dla calosci to wtedy moze sie zdazyc ze wykonanie danej sekcji bedzie trwalo zauwazalnie dlugo i inne watki beda musialy czekac zeby sie do nich dostac.
0
Johny_Morfina napisał(a)
czasem zmienna dzielona miedzy watkami jest lista obiektow i w jednej procedurze
odwoluje sie do tej listy kilka razy
(np biore pierwszy element,
cos z nim robie,
kasuje z poczatku i dodaje na koniec)wiec z tad pytanie:
Johny_Morfina napisał(a)
jest takie cos jak TMultiReadExclusiveWriteSynchronizer
czy powinienem uzywac tego do pojedynczych komend czy moge
do calych procedur (albo jeszcze wiekszych kawalkow programu)??moglbym w takiej procedurze kazde odwolanie do listy i jej obiektow oblozyc oddzielna sekcja krytyczna,
albo calal procdure do niej wpakowac. Jesli zrobie jedna sekcje dla calosci to wtedy moze sie zdazyc ze wykonanie danej sekcji bedzie trwalo zauwazalnie dlugo i inne watki beda musialy czekac zeby sie do nich dostac.
Wystarczy ze twoja lista zdziedziczy z TCriticalSection lub TMultiReadExclusiveWriteSynchronizer, wtedy kazda metode Add, Insert, Delete itd obudowujesz przed Lock(), Unlock(), BeginRead(), EndRead(), BeginWrite(), EndWrite() (w zaleznosci od sytuacji oczywiscie) i juz masz obiekt listy w pelni zabezpieczony przed wielodostepem.
Jeden obiekt synchronizujacy dla jednego obiektu synchronizowanego (powyzsze dziedziczenie elegancko zalatwia sprawe). Zabezpieczenie kazdej metody osobnym obiektem nie ma sensu, patrz przypadek Add i Delete na liscie. Te 2 operacje nie moga byc wykonane rownolegle (wiele watkow jednoczesnie), musza byc wykonane sekwencyjnie jedna po drugiej(kolejkowanie na sekcji krytyczniej), ergo musza byc synchronizowane jednym wspolnym obiektem.
ŁF napisał(a)
EgonOlsen napisał(a)
Timeout przy odczycie/zapisie property? To sa czasy liczone w nanosekundach jesli nie mniej. Raczej bardziej przejmowalbym sie deadlockami niz timeoutami przy takich operacjach. <ort>poza tym</ort> nie widze tutaj nigdzie pytania o timeouty.
nikt nie powiedział, ile trwa synchronizowana operacja, skąd wiesz, że nie kilkaset milisekund?
Johny_Morfina napisał(a)
Czy istnieja mechanizmy, ktore umozliwilyby zwrocenie 'wartosci domyslnej' albo wykonanie innych czynnosci w przypadku zablokowania dostepu do pamieci?
W kazdym razie timeouty przy operacjach np na listach sa dla mnie pewnym novum. Wydaje mi sie ze jesli lista bedzie dostatecznie duza to timeout wyskoczy zawsze gdyz operacje na tej liscie beda zabieraly <ort>co raz</ort> wiecej czasu wraz z powiekszaniem sie rozmiaru listy. Z tego wynika ze po osiagnieciu pewnej wielkosci operacje na liscie moga byc niewykonalne. A co z wolniejszymi maszynami? Rozumiem timeouty przy zagadnieniach komunikacyjnych, ale timeouty na algorytmach? Ani to sensowne ani logiczne.
// przeczytaj uważnie ostatnie zdanie z postu powyżej Twojego, zobaczysz powód - Ł