SLUPKA: Díky. Přečtu si to a půjdu asi zametat...dám na rady moudřejších.

TENCOKACISTROMY: za tohle by ho asi vyhodili, nebo tedy, pokud bych mu dal takové zadání já a on mi dal, to co ty, tak by šel určitě :))
ANDY_WARHOL: detaily? proč by programátor neměl mít alespoň nejpovrchnější základy? ono google je super, ale když nic nevíš, tak jak poznáš, že to co jsi vygooglil není špatně? zrovna u vícevláknových věcí ty chyby nejsou vidět až tak přímočaře...
P19: Tohle je úloha, která je na snad na každém začátku vysvětlování semaforů...
Producer-consumer problem - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Producer-consumer_problem

TENCOKACISTROMY: popsal si to krásně. jenže to sou ty zkusenosti co se jinak než praxi nenaucis. ovsem ty základní věcí se naučit daji poměrně lehce

ANDY_WARHOL: Coz v pripade kdy zakaznik nema nejmensi paru co po nem chces, analytik ti rekne tady jsou pravidla podle nich to udelej, tak stejne pak musis prijit s implementaci, ktera to nakonec resi.

A kdyz priste budes neco takovyho delat, tak si uvedomis na co vsechno narazis a rovnou jim to rovnou omlatis o hlavu jako nedostatecny zadani a nebo se na to aspon patricne v kodu pripravis. Tak jako tak je to dusledek "nauceni se" prace v multithreadovym prostredi.

TENCOKACISTROMY: vsak já Te chápu. ale pokud se má implementovat například to mergovani, tak analytik proste musí dat pravidla. ty mu je samozřejmě můžeš navrhnout, odmitnout , podrobit kritice ale je to on, kdo to do Te analyzi musí dat a dostat na to případně souhlas zákazníka.

ANDY_WARHOL: Jako by si to neznal - dostanes zadani a tohle nikoho nenapadlo. Pak na to narazis a co s tim mas delat? Nejak to vyresit musis a ti co ti davaji zadani si s tim rady nevedi :).

TENCOKACISTROMY: tak ja sem tu byl první kdo se nad tim podivil.
a co se Tyce toho druhého, to co naznacujes vůbec netvrdim. nicméně to co si psal je už spis Business čase než úloha z programování.

TENCOKACISTROMY: no dobře. ale to co ty popisujes se na nějakým po hovoru asi řešit nebude. to totiž hlavně musí vyřešit analýza projektu (michas tu totiž busines logiku s programováním, protože to jestli se to má mergnout a případně jak není věc peogramovani ale bc logiky). a naučit se ty hlavni zásady skutečně víc jak precist pojednáni nevyžaduje.

TENCOKACISTROMY: Navic se to temer neda automaticky testovat.

ANDY_WARHOL: Predevsim:
1) Nevytvorit si z te multithreadove aplikace aplikaci, ktera bezi ve vice threadech ale seriove (kvuli lockum).
2) Deadlocky.

A ted si predstav, ze se ti o jedny zdroje pere vic vlaken, kazdy je dulezity a kazdy musis stihnout do nejaky casu vyresit, protoze jinak skoncis na timeoutech u externich zdroju (vetsinou sitovy spojeni).

A to je teprve zacatek.
Pak je potreba vyresit konkurencni pristup kdy data ktery chces updatnout, tak pred tebou updatnul nekdo jinej - musis se rozhodnout co z toho je dobre. Bud to spravne mergnout (to jde malokdy) a nebo zrusit co jsi udelal. No jo ... ale rollbacky dneska umi temer vylucne jen databaze, software transaction memory podporuje jen malo prostredi (a .NET mezi ne nepatri).

Zrovna delame na jedny vicevlaknovy aplikaci, a fakt to neni uplne tak easy, aby jsi zajistil vysokou spolehlivost a konzistenci dat.

TENCOKACISTROMY: co na tom má byt tak sloziteho,? aby si se to za par hodin nenaucil?

P19: Nechci sejckovat, ale naucit se spravne praci s multithreadingem neni na par hodin bohuzel :(.

Chces-li to mit "hloupe" thread-safe, tak muzes udelat:

public void Enqueue(object obj) {
    lock(_locker) {
        _queue.Enqueue(obj);
    }
} 

public object Dequeue() {
    lock(_locker) {
        return _queue.Dequeue();
    }
} 

ANDY_WARHOL: jo, na tohle jsem si take vzpomnel. Problem je, ze to je az v .NET 4.0+. Na pohovoru se te treba mohou zeptat, jak bys neco takoveho imlementoval. Na to se da pripravit tak, ze si stahnes zdrojaky te Concurrent kolekce :)

MAIMONIDES: tak muze psat weby v ASP.NET nebo MVC 4 a C# :)

P19: Obecně, při vícevláknových věcech potřebuješ zajistit, že:
1. Pokud si vezmeš lock, tak ho vždy uvolníš (a to co nejrychleji). V tvém kódu je to porušeno u Dequeue nad prázdnou frontou. Formálně je ale vhodné to podobně vyřešit i u Enqueue (nikdy nevíš, co ti strčí za frontu).
2. Nikdo nečeká, až se něco stane, zatímco má lock - například pokud je fronta prázdná a ten, kdo z ní čte, čeká na příchod nové věci, zatímco má lock, tak těžko něco dostane, neboť ten, kdo do ní má něco přidat, (marně) čeká, až se lock uvolní. Porušeno to můžeš mít potenciálně tím, že Enqueue se zasekne, pokud je fronta plná.
3. Nikdo nepřistupuje k objektu bez locku a vše, co potřebuje, udělá v jedné transakci (tj. s jediným lockem). V tomto smyslu ten kód vyhovuje.