Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: hknmtt 14. 12. 2022, 19:40:58

Název: Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: hknmtt 14. 12. 2022, 19:40:58

Zaujimalo by ma ci existuje lepsie riesenie nez pouzitie atomics ak potrebujem zmenit hodnotu nejakej premennej ak ide o extremne prilezitostnu udalost? Realny priklad - potrebujem aktualizovat ssl certifikat pre beziaci server, tak mu atomicky zmenim pointer na novy. "Problem" je ze toto sa udeje iba par krat do roka(atomicky zapis), zatial co pouzitie(atomicke citanie) prebehne miliony krat. A teda ta penalizacia nastava neumerne casto nez by musela. Pouzitie atomics oproti beznej operacii je 10x pomalsie. Jasne, ide o nano-sekundy, ale ide mi o princip.

Název: Re:Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: alex6bbc 14. 12. 2022, 20:23:18

nevim zda by tohle mohlo fungovat, zadne atomicke operace s pointerem.
ale na zaklade nejake zpravy z chanelu, promenne apod. pozastavit nejak vsechny goroutiny co s tim pointerem pracuji,
pod rukama jim pointer zmenit a zase je pustit.

Název: Re:Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: hknmtt 14. 12. 2022, 20:25:35

Ano, slucku pouzivam na neblokovany(mutex-free) message broker ale v tomto pripade tento dizajn nie je pouzitelny.

Název: Re:Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: anonacct 14. 12. 2022, 20:29:11

Pokud jednou za uherský rok potřebuješ změnit hodnotu v paměti, tak na to nepotřebuješ ani atomics.

Třeba x86 nemá ani instrukce pro atomické čtení/zápis, ale má instrukce jako mfence (bariéry). Takže na x86 by bylo nejrychlejší aby všichni co tu hodnotu čtou ji četli normálně (klasický mov) a pokud ji budeš potřebovat aktualizovat, tak ji tam zapíšeš (mov) a zavoláš mfence. Během té chvilky nějaký thread ještě může přečíst starý pointer, ale nemyslím si, že to by tě to v tomto případě tankovalo.

Podle mě celkem blbý příklad pro využití atomických operací, které jsou nejvíc potřeba tam, kde se atomicky musí ta hodnota změnit a změna závisí na té předešlé hodnotě, kterou neznám a nechci číst, protože když ji přečtu tak nemám záruku, že se ta hodnota už nezměnila (fetch_add, fetch_or, fetch_and, compare_exchange, atd...)

Název: Re:Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: hknmtt 14. 12. 2022, 20:49:50

Tak asembler naozaj neplanujem riesit. Nejde o riesenie specifickeho problemu, len generalny problem(ak sa to tak vobec da nazvat). A v tomto pripade je v poriadku ak reader precita staru hodnotu. Ide len o zabrenenie toho aby doslo k citaniu a zapisu zaroven a tym padom panike.

Název: Re:Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: Wasper 14. 12. 2022, 20:58:42

Citace: anonacct  14. 12. 2022, 20:29:11

Třeba x86 nemá ani instrukce pro atomické čtení/zápis

LOCK XCHG,
LOCK CMPXCHG
První měl už 8086 blahé paměti.

Název: Re:Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: Idris 14. 12. 2022, 22:40:59

Citace: hknmtt  14. 12. 2022, 20:49:50

Tak asembler naozaj neplanujem riesit. Nejde o riesenie specifickeho problemu, len generalny problem(ak sa to tak vobec da nazvat). A v tomto pripade je v poriadku ak reader precita staru hodnotu. Ide len o zabrenenie toho aby doslo k citaniu a zapisu zaroven a tym padom panike.

Na tento typ úloh se používá RWMutex (hodně souběžných čtenářů, jeden zapisovatel), zamčení pro čtení bývá značně efektivnější než pro zápis.

Název: Re:Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: anonacct 15. 12. 2022, 11:41:46

Chce to číst až do konce před zbytečnou reakcí! Čtení a zápis v x86 je MOV a žádný LOCK MOV neexistuje, protože vzhledem k architektuře (strong ordering) to nedává smysl. Všechny další atomické operace (LOCK prefix) už něco dělají s předešlou hodnotou jako třeba LOCK ADC/ADD/SBB/SUB/OR/XOR/AND/BT/XCHG/CMPXCHG/atd...

Podle mě LOCK prefix existoval až od 386, ale hádat se nechci.

Citace: Wasper  14. 12. 2022, 20:58:42

Citace: anonacct  14. 12. 2022, 20:29:11

Třeba x86 nemá ani instrukce pro atomické čtení/zápis

LOCK XCHG,
LOCK CMPXCHG
První měl už 8086 blahé paměti.

Název: Re:Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: hknmtt 15. 12. 2022, 13:57:41

Tak tam kde som videl problem, ziaden problem na koniec nebol. Z nejakeho dovodu som mentalne riesil atomicky zapis AJ citanie(co je vlastne mutex), pritom realne staci iba atomicky zapis.

Název: Re:Go - alternativa atomics pre prilezitostne zmeny?
Přispěvatel: Ivan Brezina 16. 12. 2022, 11:26:04

Oftopic: Microsoft compilator generuje hot-patchable kod pro NT Kernel.
Zacatek kazde fce zacina:

jmp short 16
NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP NOP
...

Pocatecnich 16 NOPu se preskoci. Pri patchovani se prepisi na long jump na novou verzi fce.
Ve druhem kroku se "jmp short 16" prepise na "jmp short 0". Vyuzije se toho ze tahle instrukce ma jen 2 bajty.