środa, 6 stycznia 2021 o 15:30:01 UTC+1 fir napisał(a):
> środa, 6 stycznia 2021 o 14:46:53 UTC+1 heby napisał(a):
> > On 06/01/2021 14:40, fir wrote:
> > >> Lub wyższych koncpecji jak future/promise i thread pool.
> > > po flagach tez chyba powino dzialac...
> > Nie, ponieważ albo będzie się kręcił bez sleepa, przepalając energię,
> > albo semafor będzie szybszy od sleepa.
> >
> > W grę, z flagami, wchodzą też detale działania cache. Zmiana zmiennej w
> > CPU1 nie powoduje natychmiastowej widzialnosci w CPU2. W niektóych
> > architekturach nawet kolejnośc zmian pamięci jest nieokreślona jeśli
> > obserwujemy ją z innego rdzenia.
> > > ma to jakies minusy...sleep w windzie dziala ok z pobocznymi wątkami?
> > Sleep to najgosze co można wybrać. Nie ma żadnej zalety, a same wady.
> nie przecze ale chodzi tez o to by to zrozumiec
>
> co do przepalania rdzenia przez sleepa
> to nei ejstem zbyt przekonany co do tego czy
> jest to mozliwe bo od lat uzywam sleepa na glownym
> watku obserwujac czasy ramek i tez zuzycie procka
> w trayu i nigdy nie bylo tak by sleep nie zadzialal
> na glowym watku.. to by nie zdzialal na pobocznym tez
> wydaje mi sie wiec chyab raczej 'unexpected'
>
> moglbym to pomierzyc timerami i poobserwowac
> w zasadzie ale na razi enie che mi sie w to
> wchodzic
>
> nei wiem jak technicznie ale logicznie sleep
> jest zupelnie poprawna funkcją itd
>
> faktem jest tez jednak ze kiedys za dawnych czasow
> na jakichs kompach obserwowalem ze sleep jakby byl
> czasem nie wiadomo w zaleznosci od czego
> wyrownywany do 15 ms nawet jak wolane bylo 5 ms
> ale od lat tego nei widzialem mozliwe ze to bylo
> tylko na jednordzemiakach
>
> co do tego synchronizowania flafami tez nie jestem
> pewien czy to jest zle, jak mowie zrobilem to i
> raczej dzialalo choc nie robilem dokladnych
> testow timerami itd - kwestia jest taka ze w tym
> akurat kodzie o ktorym mowie mozna bylo zrobic na
> lajcie tak by kazdy watek pisal do swojej flagi
> a glowny tylko je czytal wiec nie bylo tak ze
> jakies dwa pisaly do wspolnej flagi, nawet
> jakby cos tam sie w czasie rozminelo o pare
> mikrosekund miedzy watkami to tez nie robiloby
> to problemu co najwyzej jeden poczekalby tego
> jednego sleepa wiecej
>

logicznie to raczej trzymalo sie kupy (to czyli synchrronizacja na sleepach i
flagach) wiec i technicznie
mogloby sie trzymac o ile te sleepy albo watki nie wykazywaly jakichs wewnetrznych
nie znanych mi cech powodujacych ze cos tu jest nie tak

co troche nawiazuje do starego watku na CLC gdzie pisalem jak pamietam uzytkownikowi
AL ze mozna synchronizowac watki nawet bez atomikow (na podobnej zasadzie o ile
pamietam tylko nawet w drobniejszej skali czasowej, obecnie troche nie pamietam
tamtego przykladu)

jesliby sie okazalao ze ta watki czy sleepy maja jakies cechy ktore powoduja ze sie
nie sprawdzaja w tego typu kodzie to troche kiepsko bo fajnie by bylo jakby ludzie
projektowali rzeczy na taki nazwijmy to "woluntarystyczny" sposob ;c

> ale pewnie bedzie trzena poczytac wiecej
> faktycznie o tych wspomnianych rzeczach
> (na poczatek uzywalbym raczej tych prostszych)
>
> tenx za informacje bo byly pomocne, mam jakis obraz
> co i jak