What should all developers even rubyist know about threads: http://rubyconf2008.confreaks.com/what-all-rubyist-should-know-about-threads.html. Vlákna jsou obtížný a hlavně zastaralý koncept pro vývojáře. Programovat vlákna je strašně těžké a nikdo kromě vývojářů jádra, programovacích jazyků, virtuálních strojů a dalších úzce specializovaných věcí by neměl být nucen je programovat protože v tom naseká mraky chyb. Tak jako od dob Javy a dalších vyšších jazyků nejsou programátoři nuceni řešit GC, meze polí a další, tak by na začátku 21. století neměl být nucen řešit problémy s vlákny, zámky a semafory na takto nízké úrovni. Je načase se ohlédnout po lepší abstrakci třeba v jazycích jako Erlang, Clojure, F#, (J)OCaml, Oz (Mozart) nebo něčem podobném. Osobně doporučuji ten první.
IMO dost zalezi, co pisete. U neceho je paralelizace vlakny snadna a vykon lepsi nez u paralelizace typu erlang (ostatni zminene neznam). U jineho problemu se pri efektivni implementaci vlakny pekne zapotite. Myslim si, ze je dobre znat oba zpusoby a podle typu problemu si vybrat.
Take si myslim, ze jsou problemy, ktere jsou paralelizovatelne velmi snadno a nopak jsou problemy, kde paralelizace je budto nemozna, nebo tak obtizna, ze za to nestoji. Klasickym pripadem prvniho typu je raytracing - po te, co se scena predzpracuje, se muze teoreticky kazdy pixel renderovat zvlast. Naopak numericke vypocty pomoci iteraci, pri kterych je pro vypocet nasledujiciho kroku nezbytne nutna hodnota z kroku predchoziho, se paralelizovat temer neda.
Bať a to se psal rok 1995. Jen bych nesouhlasil s Concurrency is fundamentally hard; avoid whenever possible. S Erlangem je concurrency celkem hračka i když i tam člověk může udělat chybu, ale je to řádově jednodušší než s vlákny. Jenže v té době byl ještě držen pod pokličkou v Ericssonu i když už měl za sebou deset let vývoje.