Go - alternativa atomics pre prilezitostne zmeny?

hknmtt

Go - alternativa atomics pre prilezitostne zmeny?
« kdy: 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.


alex6bbc

  • *****
  • 1 431
    • Zobrazit profil
    • E-mail
Re:Go - alternativa atomics pre prilezitostne zmeny?
« Odpověď #1 kdy: 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.

hknmtt

Re:Go - alternativa atomics pre prilezitostne zmeny?
« Odpověď #2 kdy: 14. 12. 2022, 20:25:35 »
Ano, slucku pouzivam na neblokovany(mutex-free) message broker ale v tomto pripade tento dizajn nie je pouzitelny.

Re:Go - alternativa atomics pre prilezitostne zmeny?
« Odpověď #3 kdy: 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...)

hknmtt

Re:Go - alternativa atomics pre prilezitostne zmeny?
« Odpověď #4 kdy: 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.


Re:Go - alternativa atomics pre prilezitostne zmeny?
« Odpověď #5 kdy: 14. 12. 2022, 20:58:42 »
Třeba x86 nemá ani instrukce pro atomické čtení/zápis
LOCK XCHG,
LOCK CMPXCHG
První měl už 8086 blahé paměti.

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Go - alternativa atomics pre prilezitostne zmeny?
« Odpověď #6 kdy: 14. 12. 2022, 22:40:59 »
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.

Re:Go - alternativa atomics pre prilezitostne zmeny?
« Odpověď #7 kdy: 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.

Třeba x86 nemá ani instrukce pro atomické čtení/zápis
LOCK XCHG,
LOCK CMPXCHG
První měl už 8086 blahé paměti.

hknmtt

Re:Go - alternativa atomics pre prilezitostne zmeny?
« Odpověď #8 kdy: 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.

Re:Go - alternativa atomics pre prilezitostne zmeny?
« Odpověď #9 kdy: 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.