Mutex

21.3.2007 16:25 | Přečteno: 2302× | to su Veci | poslední úprava: 21.3.2007 16:27

Pracujem na jednom projekte, v ktorom sa spúšťa jeden malý program veľký počet krát (rádovo stovky) a pri každom spustení potrebuje vygenerovať unikátne meno výstupného súboru a odovzdať ho inému procesu. Utilitka môže bežať na viacerých klientoch naraz a výstupný súbor bude vznikať na serveri v čase, keď už utilitka nebeží.

Čo s tým? Jednoduché. Meno sa generuje podľa aktuálneho času s presnosťou na milisekundu, prihodí sa meno klienta, celé sa to zabalí do mutexu a v mutexe sa počká dlhšie ako 1ms. Akurát, že to nefunguje. Teda väčšinou to funguje. Na mojom stroji je to OK. Na testovacom stroji 700 km ďaleko tiež. Ale na nejakom stroji kdesi v XY v necelom percente pripadov to vygeneruje opakujuci sa identifikator.

Záhada.

Tu je kód:

void UniqueName(char *buffer)
{
  struct timeval tv;
  sem_t *mutex=NULL;
  char hostname[100];

  if (!gethostname(hostname,sizeof(hostname)))
  {
    mutex=sem_open("MyMutex",O_CREAT,0700,1);
    if (mutex!=SEM_FAILED)
    {
      sem_wait(mutex);
      gettimeofday(&tv,NULL);
      sprintf(buffer,"%s-%d-%d\n",hostname,tv.tv_sec,tv.tv_usec);
      usleep(5000);
      sem_post(mutex);
      sem_close(mutex);
    }
    else
        perror("sem_open");
   }
}

Pôvodný kód je na Win32, takže som sa povŕtal v tom, ako sa to robi na Linuxe. Treba mať jadro 2.6, glibc s NPTL, bežiaci udev a permission na /dev/shm. V originále sú ošetrené všetky systémové volania a žiadne nezlyhá.

No a pointa? Mám teóriu, prečo ten kód zlyháva. A je taká bláznivá, že som chcel počuť najprv nápady od vás. Tak čo si myslíte?        

Komentáře

[disorder]

prestal som citat asi v bode, kde som sa dozvedel ako sa generuje to "unikatne meno". chyba je tam.

man 3 tmpfile

[rastos]

Tak si nečítal pozorne. Ten súbor nevzniká v čase, keď sa to meno generuje. Môže vzniknúť o minútu, alebo aj o pol hodinu. Na inom stroji, z iného programu.

[disorder]

to ze som prestal citat som nenazval pozornym citanim

[Luk]

V každém případě je odvozování unikátních názvů souborů od času hrubou chybou. Je nezanedbatelná pravděpodobnost, že se může stejný název vygenerovat víckrát.

Pro rozumně unikátní názvy lze použít například funkci uuid_generate().

[rastos]

Ako tak čítam tú stránku, tak sa použije aj current time v spojení s /dev/urandom. Je to v princípe riešenie, ktoré mi bolo navrhované ešte než som poznal príčinu zlyhania môjho kódu, ale nebolo mi sympatické pretože chovanie nie je "deterministické" (a generovaný string je dlhý). Ale nakoniec ho asi budem musieť použiť. Dík za tip.

[petr_p]

Mne se to take nelibi. Jedinecnost neni garantovana, spoleha se ciste na pravdepodobnost (zvlaste dobra je argumentace v manualu :)

[Luk]

Problém je v tom, že není žádná obecně použitelná cesta, jak tu skutečnou jedinečnost zajistit. Komu by to nestačilo takhle, může si přidat čítač, jehož hodnota bude použita jako součást identifikátoru.

[Lu-Tze]

V kódu chybu nevidím (to nic neznamená), ale divím se, že pracuješ s časem. Čas je hračka pro pro fyziky, filosofy a jiná individua. Asi bych to řešil přes sdílenou paměť, do které bych zapisoval hodnotu čítače (a při každém požadavku na vygenerování čítač inkrementoval, na samém počátku by se mohl iniciovat třebas tím časem, pokud bys to neměl vyřešeno jinak).

[Lu-Tze]

Utilitka môže bežať na viacerých klientoch naraz a výstupný súbor bude vznikať na serveri v čase, keď už utilitka nebeží.

Aha, to jsem prve pochopil špatně. Teď už to nechápu vůbec. Jméno generuješ na klientech?

[rastos]

> Asi bych to řešil přes sdílenou paměť, do které bych zapisoval hodnotu čítače

To by som tú pamäť musel zdieľať medzi viacerými strojmi v sieti.

> > Utilitka môže bežať na viacerých klientoch naraz a výstupný súbor bude vznikať na serveri v čase, keď už utilitka nebeží.

> Aha, to jsem prve pochopil špatně. Teď už to nechápu vůbec. Jméno generuješ na klientech?

Áno meno sa generuje na klientoch. Nechcem zachádzať do podrobností, ale skrátka ide o systém, do ktorého sa pumpujú úlohy, ktoré treba spočítať. Skupina úloh sa nachystá na klientovi a potom sa spustí dávka, ktorá ich postupne poodosiela na spracovanie na serveri. Súbor vznikne, až keď sa úloha dostane na rad a začne sa skutočne počítať.

Vlastne nejde len o výstupný súbor. Podobný mechanizmus je použitý aj na iných miestach, ale princíp ostáva.

[Lu-Tze]

To by som tú pamäť musel zdieľať medzi viacerými strojmi v sieti.

To přece ne, stačí, když ty klienty očísluješ. Čísla jim buď může přiřazovat server nebo jde-li o uzavřený systém, tak je můžeš očíslovat předem.

[...............23]

Ale na nejakom stroji kdesi v XY v necelom percente pripadov to vygeneruje opakujuci sa identifikator.

A nebeží na tom stroji náhodou nejaký démon na synchronizáciu času alebo niečo také?

[podlesh]

To nebyl dobrý nápad.

[jekub]

A nepředbíhají se na stroji v XY hodiny a neběží tam v cronu nějaká časová synchronizace?

[rastos]

Zásah. Presne v tom spočíva moja teória. Získavaš 10 bodov

[petr_p]

Stavite na predpokladech, ze

• Kazdy stroj ma jedinecny hostname
• Cas na na kazdem stroji bezi jednim smerem (tj. mezi gettimeofday() nikde nehne zpet s casem)
• usleep() se muze ovlivnovat s jinymi funkcemi, napr. s alarm()em

A obecne spat v kriticke sekci je opravdu zavrzenihodne.

[rastos]

> Kazdy stroj ma jedinecny hostname

To je, podľa mňa, celkom pravdivý predpoklad. Keby neplatil, tak by to spôsobovalo kadejaké iné problémy, ktoré by sa prejavili skôr. Môžem mať v NT doméne dva stroje s rovnakým hostname?

> Cas na na kazdem stroji bezi jednim smerem

Tento predpoklad je skutočne mylný, pretože ten stroj, kde problém vzniká si synchronizuje čas (čo je defaultne vypnuté) a mňa to jednoducho nenapadlo.

> usleep() se muze ovlivnovat s jinymi funkcemi, napr. s alarm()em

To je pravda, ale o tom, že dôjde k alarm()-u, by som sa dozvedel z toho, že sa urobí jeho obsluha.

[miso]

> Kazdy stroj ma jedinecny hostname To je, podľa mňa, celkom pravdivý predpoklad. Keby neplatil, tak by to spôsobovalo kadejaké iné problémy, ktoré by sa prejavili skôr. Môžem mať v NT doméne dva stroje s rovnakým hostname?

Stroj moze mat iny hostname a iny zaznam v dns (inac sa vidi on sam a inac ho vidia ostatne stroje).
A to nehovorim o /etc/hosts (localhost, viac vlastnych IP), zalezi akou funkciou ziskavas vlastny hostname

[petr_p]

Cas na na kazdem stroji bezi jednim smerem

Tento predpoklad je skutočne mylný, pretože ten stroj, kde problém vzniká si synchronizuje čas (čo je defaultne vypnuté) a mňa to jednoducho nenapadlo.

Rozumne implementace synchronizatoru casu meni cas postupnym spomalovanim nebo zrychlovanim a to na urovni jadra, takze by se cas nemel vracet zpet. (Tj. spoustet kazdou hodinu ntpdate je spatne, ale nechat bezet ntpd je dobre.)

usleep() se muze ovlivnovat s jinymi funkcemi, napr. s alarm()em

To je pravda, ale o tom, že dôjde k alarm()-u, by som sa dozvedel z toho, že sa urobí jeho obsluha.

Nejde jen o alarm(), tech nebezpecnych funkci je mnohem vice. Ale predpokladam, ze vite, co delate.

[Filip Jirsák]

Rozumne implementace synchronizatoru casu meni cas postupnym spomalovanim nebo zrychlovanim a to na urovni jadra, takze by se cas nemel vracet zpet. (Tj. spoustet kazdou hodinu ntpdate je spatne, ale nechat bezet ntpd je dobre.)

Což platí jen v případě, že je čas posunutý jen málo. Pokud se čas od přesného času liší třeba o několik dní, není možné jej synchronizovat tak, že několik týdnů poběží hodiny rychleji/pomaleji.

[wake]

ano. proto se ntpdate spousti pri bootu, aby se hodiny syncly 'nahrubo', vzapeti se spusti ntpd, ktery se postara o "spojite" udrzovani presneho casu a driftfajlu. (jak moc se mi ty hodiny v HW vlastne predbihaji?)

[Filip Jirsák]

jak moc se mi ty hodiny v HW vlastne predbihaji?

Některé dost Problém je, že ntpdate při bootu nemusí čas sesynchronizovat vždy správně (např. během bootu není dostupný internet, třeba i jen z toho důvodu, že po výpadku proudu nabootuje router později, než ntpdate na jiném PC). A navíc ntpd nemá moc rádo výpadky internetu – dokáže v takovém případě přestat synchronizovat čas, ale démon běží dál, takže na první pohled nic nepoznáte. Jednou mi tahle kombinace způsobila to, že na serveru, který s ejinak normálně synchronizoval, běžel démon ntpd, ale čas byl posunut o několik měsíců…

[petr_p]

Coz je problem konkretni implementace (mozna i specifikace).

Kdyz budu pozadovat relativne presny cas, tak si proste pockam. (Napr. autorita vydavajici casova razitka si rozhodne netroufne zacit pracovat, aniz by mela overeno, ze ma spravny cas.)

[wake]

co treba blocking ntpdate? while ! (ntpdate ser.ver); do true; done

[wake]

dd if=/dev/urandom bs=256 count=1 2>/dev/null | md5sum --binary| cut -d ' ' -f 1