-
Data: 2021-01-06 16:38:14
Temat: Re: zapytanie o thready
Od: fir <p...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]środa, 6 stycznia 2021 o 16:29:44 UTC+1 fir napisał(a):
> środa, 6 stycznia 2021 o 16:06:52 UTC+1 heby napisał(a):
> > On 06/01/2021 15:41, fir wrote:
> > > ze mozna synchronizowac watki nawet bez atomikow
> > W ogómym przypadku to nie jest skuteczne. W przypadku architektury x86
> > może być czasem możliwe.
> >
> > W bardzo ogólnym wypadku wymagany jest choć fence, który trzeba jawnie
> > uzyć w kodzie programu. Taki mechanizm w CPU który zapewnia
> > synchronizację dostępu do pamięci między różnymi rdzeniami i cache.
> >
> > Tak więc ogólnie rzecz biorąc nie da się zrobić sensownej synchronizacji
> > tylko na spilockach bo to zależy na czym to ma pracować. Zwyczajowo w
> > świecie wielordzeniowym trzeba się badziej postarać niż while(!flag) { }.
> while z pust apetla bym nei uzyl ale ze sleepem 2-3 milisekundy nie wydaje mi sie
juz tak glupie..ogolne programowanie tez mnie nie kreci bo ogolne programowanie to
zle porogramowanie bo w ogolnosci nie dziala optymalnie na specyficznych maszynach ;c
>
> schemat btw raczej jaki wymodzilem byl raczej taki
>
> int ready = 0;
> do
> {
> while(current<ready) { sleep(2); }
> do_work();
> ready++;
> } whie(1);
>
> cos w tym stylu, robota dzielona na porcje numerowane liczba naturalna, current
zaczyna sie od -1,
> boczne watki czekaja na sleepach; glowny thread robi current++ do 0 wati ruszaja az
ustawia ready na 1
> glowny watek sprawdza czy wszystkie maja ready wieksze niz current jesli tak
popycha current itd
>
> w moim przekonaniu to raczej chyba powinno dzialac
przez powinno mam na mysli ze odpalilem to i dzialalo (ale nie ejestem pewien czy
nei przegapilem jakichs wzglednych subtelnosci), current to oczywoscie odpowiada
numerowi ramki obrazu w symulacji ktora dzialac ma na okolo 50-120 fps na jednym
watku zajmowala ok 30 ms na ramke wiec w optymalnym podziale roboty powinno wyjsc po
15 ms na rdzen na dwurdzeniaku... nie mierzylem czasu tylko patrzylem na oko czy jest
szybciej i wylogowalem tez stany tych ready i current do loga textowego i na oko
wygladalo ok
aczkolwiek zawsze jak ktos wie co tu sie moze realnie chcrzaic to wiedza o detalach
mile widziana
(fir)
Następne wpisy z tego wątku
- 07.02.21 12:53 M.M.
Najnowsze wątki z tej grupy
- Alg. kompresji LZW
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
Najnowsze wątki
- 2025-02-17 Kraków => MS Dynamics 365BC/NAV Developer <=
- 2025-02-17 Chrzanów => Programista NodeJS <=
- 2025-02-17 Warszawa => Node.js / Fullstack Developer <=
- 2025-02-17 Białystok => System Architect (Java background) <=
- 2025-02-17 Białystok => Solution Architect (Java background) <=
- 2025-02-17 Gliwice => Team Lead / Tribe Lead FrontEnd <=
- 2025-02-17 Gdańsk => PHP Developer <=
- 2025-02-17 Warszawa => Senior ASP.NET Developer <=
- 2025-02-17 Gliwice => Business Development Manager - Network and Network Security
- 2025-02-17 Mińsk Mazowiecki => Area Sales Manager OZE <=
- 2025-02-17 Odśnieżanie samochodu
- 2025-02-17 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2025-02-17 Dęblin => JavaScript / Node / Fullstack Developer <=
- 2025-02-17 Pompiarze...
- 2025-02-16 PV teraz