abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 11:55 | Nová verze

    UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.

    Ladislav Hagara | Komentářů: 0
    dnes 11:33 | IT novinky

    Společnost Škoda Auto zveřejnila na Printables bezplatné 3D modely příslušenství do svých vozů (držáky na nápoje, pomůcky pro vedení kabelů, mincovníky, háčky na USB kabely a čepice pro kapsy na zadních stranách opěradel sedadel, držáky na telefony a úchyty pro horní upevnění bezpečnostních pásů).

    Ladislav Hagara | Komentářů: 3
    dnes 05:11 | Zajímavý článek

    Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 170 (pdf).

    Ladislav Hagara | Komentářů: 0
    dnes 04:33 | Bezpečnostní upozornění

    Dnes v 16:00 (14:00 UTC) budou opraveny 2 kritické zranitelnosti s CVSS 9.2 v PHP.

    Ladislav Hagara | Komentářů: 3
    dnes 01:37 | Bezpečnostní upozornění

    Nizozemská policie 13. října 2026 zabavila v datacentru Amsterdam Science Park server italského poskytovatele internetových služeb Autistici/Inventati (A/I), a to na základě americké žádosti o mezinárodní právní pomoc.… více »

    vencour | Komentářů: 4
    včera 20:47 | Bezpečnostní upozornění
    Hlášeny RCE v NGINX. Náprava dostupná. … více »
    vencour | Komentářů: 0
    včera 20:33 | IT novinky

    Do 26. října do 18:00 běží na Steamu přehlídka nadcházejících her Festival Steam Next | říjen 2026 (YouTube) doplněná demoverzemi, přenosy a dalšími aktivitami. Demoverze lze hrát zdarma.

    Ladislav Hagara | Komentářů: 0
    včera 20:22 | Zajímavý software

    Čínská technologická společnost DeepSeek zveřejnila na GitHubu svůj framework DeepInfer, nástroj pro efektivní offline inferenci svého modelu DeepSeek-V4.1-Flash ve velkém měřítku. Software běží na Linuxu a nativně podporuje akcelerátory Nvidia ale i čipy Huawei Ascend 950. Jedná se pouze o samotný inferenční engine, ne kompletní produkční službu. Zdrojový kód je dostupný pod licencí Apache 2.0.

    ❗Červivý Hřib krade❗ | Komentářů: 0
    včera 17:00 | Nová verze

    Německo-americká společnost Black Forest Labs představila FLUX 3 Image Klein, otevřený model s 5,6 miliardami parametrů pro tvorbu a úpravu obrázků. Dovede pracovat až s deseti referenčními snímky a zvládá generování v rozlišení až 4K, díky své menší velikosti ('klein' v němčině znamená 'malý') je model vhodný pro používání na běžných grafických kartách. Jedná se bohužel o cenzurovaný generativní model, z korpusu byl před trénováním

    … více »
    ❗Červivý Hřib krade❗ | Komentářů: 6
    včera 11:33 | Nová verze Ladislav Hagara | Komentářů: 1
    Které desktopové prostředí na Linuxu používáte?
     (9%)
     (7%)
     (4%)
     (21%)
     (30%)
     (8%)
     (5%)
     (2%)
     (14%)
     (20%)
    Celkem 2885 hlasů
     Komentářů: 33, poslední včera 23:44
    Rozcestník

    Administrace komentářů

    Jste na stránce určené pro řešení chyb a problémů týkajících se diskusí a komentářů. Můžete zde našim administrátorům reportovat špatně zařazenou či duplicitní diskusi, vulgární či osočující příspěvek a podobně. Děkujeme vám za vaši pomoc, více očí více vidí, společně můžeme udržet vysokou kvalitu AbcLinuxu.cz.

    Příspěvek
    19.6.2009 00:45 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Tak tohle je průšvih.

    Děkuji všem za komentáře a zejména za odkazy na zajímavé články. Nicméně právě teď jsem udělal praktický pokus s ošklivými spinlocky. Výsledek mě vyděsil. Posuďte sami. Většina toho, co tu zatím bylo řečeno, zcela zjevně není pravda.

    Tady je zdrojový kód:

    #include <unistd.h>
    #include <limits.h>
    #include <stdio.h>
    #include <pthread.h>
    #include <time.h>
    
    static const struct timespec snooze = { 5, 0 };
    
    static int useless;
    static int flag = 1;
    static volatile int FLAG = 1;
    
    static void foo( void ) {}
    static void FOO( int * something ) { useless = *something; }
    
    static void * t1( void * param ) { while ( flag ); puts( "T1 finished." ); return NULL; }
    static void * t2( void * param ) { while ( flag ) foo(); puts( "T2 finished." ); return NULL; }
    static void * t3( void * param ) { while ( flag ) FOO( &flag ); puts( "T3 finished." ); return NULL; }
    static void * t4( void * param ) { while ( FLAG ); puts( "T4 finished." ); return NULL; }
    static void * t5( void * param ) { while ( FLAG ) foo(); puts( "T5 finished." ); return NULL; }
    
    void * ( * const func[ 5 ] )( void * ) = { t1, t2, t3, t4, t5 };
    
    int main( void ) {
            int i;
            pthread_attr_t attr;
            pthread_t threads[ 5 ];
    
            pthread_attr_init( &attr );
            pthread_attr_setstacksize( &attr, PTHREAD_STACK_MIN );
    
            puts( "Spawning threads." );
            for ( i = 0; i < 5; ++i ) pthread_create( &threads[ i ], &attr, func[ i ], NULL );
            nanosleep( &snooze, NULL );
    
            puts( "Setting the death flag." );
            FLAG = flag = 0;
            nanosleep( &snooze, NULL );
    
            puts( "That's the end." );
            return 0;
    }
    

    Ano, je to moc ošklivý kód. Ano, nevolám nikde pthread_join(). (To jsou reakce na předpokládané FAQ.) A tady jsou výsledky, ze kterých mrazí v zádech.

    [andrej@argos pokusy]$ gcc -O0 -pthread spin.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    Setting the death flag.
    T4 finished.
    T2 finished.
    T1 finished.
    T5 finished.
    T3 finished.
    That's the end.

    Tak tady je vše podle předpokladů. Při -O0 se proměnná čte vždy znovu z paměti.

    [andrej@argos pokusy]$ gcc -O1 -pthread spin.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    Setting the death flag.
    T5 finished.
    T4 finished.
    That's the end.
    

    Tady se čtou pouze volatile proměnné. Druhé a třetí vlákno proměnnou flag nepřečtou znovu, přestože se pointer na ni předává ven a přestože se v cyklu volá funkce! Při -O2 a -O3 se to chová stejně. Co když teď zdrojový kód trochu pozněníme...?

    --- spin.c      2009-06-18 23:46:52.000000000 +0200
    +++ spin2.c     2009-06-18 23:51:55.000000000 +0200
    @@ -11,7 +11,7 @@
     static volatile int FLAG = 1;
    
     static void foo( void ) {}
    -static void FOO( int * something ) { useless = *something; }
    +static void FOO( int * something ) { ++( *something ); }
    
     static void * t1( void * param ) { while ( flag ); puts( "T1 finished." ); return NULL; }
     static void * t2( void * param ) { while ( flag ) foo(); puts( "T2 finished." ); return NULL; }

    Teď jde opravdu do tuhého a nastává zmatek, jaký jsem ještě neviděl.

    [andrej@argos pokusy]$ gcc -O0 -pthread spin2.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    Setting the death flag.
    T4 finished.
    T5 finished.
    T2 finished.
    T1 finished.
    That's the end.

    Naprosto špatně. Vlákno T3 by mělo skončit první, ale neskončí vůbec. Proměnnou v cyklu nečte i přesto, že je vypnutá optimalizace a že ji předává jiné funkci, která ji pozmění! Dobře, zkusme optimalizaci zapnout.

    [andrej@argos pokusy]$ gcc -O1 -pthread spin2.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    T3 finished.
    Setting the death flag.
    T4 finished.
    T5 finished.
    That's the end.

    Ano, takhle to má podle předpokladů (ne)fungovat... O stupeň vyšší optimalizace se chová stejně. Ale u -O3 číhá ošklivé překvapení:

    [andrej@argos pokusy]$ gcc -O3 -pthread spin2.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    T3 finished.
    T1 finished.
    Setting the death flag.
    T4 finished.
    T5 finished.
    That's the end.

    Tohle už je opravdu těžko vysvětlitelné. Teď znovu vyzkouším první zdrojový kód, jen s jiným kompilátorem:

    [andrej@argos pokusy]$ icc -O0 -pthread spin.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    Setting the death flag.
    T4 finished.
    T5 finished.
    T3 finished.
    T2 finished.
    T1 finished.
    That's the end.

    Tady žádné překvapení nečíhá.

    [andrej@argos pokusy]$ icc -O1 -pthread spin.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    T1 finished.
    T2 finished.
    T3 finished.
    Setting the death flag.
    T5 finished.
    T4 finished.
    That's the end.

    Ale toto je prosím pěkně neuvěřitelné. Kompilátor přesunul přiřazení globální proměnné přes několik volání funkcí! Netvrdil tu někdo před chvílí, že to není možné? Jedině volatile proměnná byla přiřazena (a přečtena) ve správnou dobu. Vyšší stupně optimalizace se chovají stejně.

    Nyní znovu vyzkouším pozměněný zdroják s kompilátorem Intel.

    [andrej@argos pokusy]$ icc -O0 -pthread spin2.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    Setting the death flag.
    T2 finished.
    T1 finished.
    T4 finished.
    T5 finished.
    T3 finished.
    That's the end.

    Toto je další odlišnost od GCC. Tentokrát skončila všechna vlákna. Nicméně vyšší úrovně optimalizace přinesou další překvapení:

    [andrej@argos pokusy]$ icc -O1 -pthread spin2.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    T2 finished.
    T1 finished.
    Setting the death flag.
    T5 finished.
    T4 finished.
    That's the end.

    Další podivný výsledek. Jedno z vláken neskončilo a tento stav se nepodobá žádnému z předchozích.

    [andrej@argos pokusy]$ icc -O2 -pthread spin2.c -o spin
    [andrej@argos pokusy]$ ./spin
    Spawning threads.
    T1 finished.
    T2 finished.
    T3 finished.
    Setting the death flag.
    T4 finished.
    T5 finished.
    That's the end.

    A zvýšení stupně optimalizace to zase dá do pořádku, přestože jde o jiný kompilátor a jiný stupeň optimalizace. Třetí stupeň se chová stejně.

    Jaké je ponaučení z tohoto pokusu?

    1. Kompilátor umí optimalizovat přístupy do paměti přes volání jakýchkoliv (i knihovních!) funkcí.
    2. Přes volání statických funkcí optimalizuje kompilátor skoro vždy a nelze tomu zabránít.

    3. Schopnost gcc zjistit, zda je volané funkci předáván pointer na danou proměnnou a zda ji tato volaná funkce může nebo nemůže změnit, zjevně závisí na zvolené úrovni optimalizace. (!!!) Výsledky z GCC po aplikaci patche to jasně ukazují. Tohle se vůbec netýká vláken a mohl by to být bug v kompilátoru.

    A jeden fakt na závěr: Vlákna čtoucí volatile proměnnou neselhala ani jednou. Ostatní selhala téměř vždy, přestože podle většiny odpovědí v této diskusi by selhat neměla!

    Jestliže kompilátor dokáže přesouvat přiřazení globální proměnné přes několik systémových volání, přes vytváření vláken a dokonce i přes nanosleep(), jak má potom člověk věřit, že je nebude přesouvat přes synchronizační primitiva?

    Když může přiřazení do globální proměnné přeskočit nanosleep(), proč by nemohlo přeskočit pthread_cond_wait() nebo pthread_cond_signal()? Jak je možné, že vůbec nějaká synchronizace funguje? Možná mi budete spílat, ale pro mě je závěr z tohoto pokusu jednoznačný: volatile vždy a všude!

    Tak teď jsem z toho jelen.

    V tomto formuláři můžete formulovat svou stížnost ohledně příspěvku. Nejprve vyberte typ akce, kterou navrhujete provést s diskusí či příspěvkem. Potom do textového pole napište důvody, proč by měli admini provést vaši žádost, problém nemusí být patrný na první pohled. Odkaz na příspěvek bude přidán automaticky.

    Vaše jméno
    Váš email
    Typ požadavku
    Slovní popis
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.