NECROMAN: Ja ho pouzil akorat na story board. Jinak se mi to k nicemu pouzivat nepovedlo.

TENCOKACISTROMY: no Blend pouzivam skoro denne, ale ten zbytek - souhlas.

Microsoft oznamil konec vyvoje Expression Studio. Expression Design a Encoder 4 bude zdarma ke stazeni, Blend bude prozatim soucasti instalace Visual Studia. Jak to bude dal se zatim nevi, ani puvodni web uz jim nefunguje.

SLUPKA: jo jasne, to mas asi pravdu.
bral sem to moc ultimatne.
ale jasne kdyz to chteji predem, tak to proste muze vypracovat jako by si to udelal na projektu.
priznam se, ze ja sem v zivote prijimal jenom jednoho cloveka, takz moje zkusenosti v personalistice programatoru valne nejsou :)

ANDY_WARHOL: proč by ti to machr neměl napsat? co to je semafor snad ví všichni... a i kdyby, machr to dokáže napsat pomocí pár bool proměnných a to jim teprve spadne brada :))

hlavně, ty tady vycházíš z toho: nenapíšeš = místo nedostaneš, napíšeš = místo dostaneš... hodně bych se divil, že by to tak bylo... většinou se spíš hodnotí, co u toho říkáš, jak přemýšlíš, než jak moc dokonalé a neprůstřelné je tvoje okamžité řešení... a pokud dostávají něco co mají udělat předem, tak je to stejně jen prvotní filtr na úplné blbečky co neumí používat google apod. :))

SLUPKA: no to ano, to zalezi. ale ted si vem, ze takhle vyradis predem programatora, co se sice venoval predtim jinem vecem, ale muze to bejt machr, kterej se do tyhle problematiky dostane behem par dnu aniz by mu to delalo nejaky zvlastni problemy. ten ti to z fleku nenapise na nejakym pohovoru, pritom by mohl byt lepsi, nez ten co ti to napise.
proto je nesmysl, chtit nejaky takovy podrobnosti.

ANDY_WARHOL: tak záleží, co jde programovat... někde to může potkávat neustále...

nebude... ale dáš mu pár otázek a už víš na čem jsi :))

SLUPKA: no prave, ja delam programatora vic jak deset let, z toho vetsi cast v netu a muzu rict, ze ac sem delal ruzny veci, tak vylozene neco opravdu thread bezpecnyho jsem potreboval udelat jednou (ti myslim neco opravdu kritikal, samozrejme drobnejsi veci, typu timer nepocitam). a abych potreboval pouzit objekt typy quene, to bylo snad dvakrat.
Presto si troufam tvrdit, ze kdyby to bylo potreba, tak bych to vyresil a to vcetne pripadnyho mergingu pokrocilych datovych struktur v pripade konkurecniho pristupu.
z toho odvozuju, ze to co chteli po nem je uz moc konkretni. a stejne to nic nevypovi o tom, jeslti mu to mysli. tedy ne politicky ale programatrosky :)
a imho, on si to tady s nama skonzulutuje a prinese nejaky reseni, ktery nebude uplne jeho. bude to nejaky dukaz, ze umi programovat ?

ANDY_WARHOL: jo, tak s tím souhlasím... pak už je to jen o tom, kde je ta hranice, co by člověk měl znát (neříkám detailně, ale alespoň aby věděl přesně co googlit) a co už je moc konkrétní...

SLUPKA: jen si nepochopil jak sem to myslel. ME by u najimaneho programátora spis zajimalo, zda umí vymyslet řešení neboli algoritmizovat, než jestli zná nějakou zcela konkrétní věc, protože to ze by něco dokázal vypsat z ruky v žádném případě ne indikuje, ze by byl v reálné praxi použitelnější než ten co by to nevypsal.

Mimochodem - semafory v .NETu nezajistujou poradi pristupu threadu ktery cekaji.
Sam jsem to do dneska nevedel. Budiz mi omluvou, ze je nepouzivam.

Nekdy to je fuk, ale zrovna u fronty bych rekl ze to muze byt problem.

Sry, já jsem si to blbě přečetl, co bylo za zadání. Jsem myslel, že má frontu s omezenou kapacitou. Pokud jen frontu, tak lock (semafor velikosti 1) to řeší. Případně kdybys udělal vlastní implementaci fronty (třeba spojákem), tak to uděláš thread safe, kde se zápis / čtení budou ovlivňovat jen při práci se (skoro) prázdnou frontou, což ti semafor přesně vyřeší...

TENCOKACISTROMY: Tim nepomoci semaforama jsem mel na mysli oproti locku. Semaforama to samozrejme vyresit lze.

SLUPKA: me prijde reseni TCKS naprosto OK, semafor je v tomhle pripade trochu zavadejici, ale porad teda pouzitelnej (i kdyz reseni pres lock je rozhodne bezpecnejsi co do moznosti nasekat tam chyby). K fronte muze soucasne pristupovat jenom jeden proces, takze semafor bude muset mit maximalni hodnotu 1 (u bezny .net queue nejde zarucit, ze paralelni cteni, nebo zapisy neskonci spatne). To je jedna polovicka problemu. Ta druha jsou waity a tam je pokud jsem se spravne dival v .netu trochu problem, protoze neni synchronyzacni primitivum, ktery by se chovalo jako WaitHandle s counterem, umi jenom bit. Takze krome WaitHandle jeste budu potrebovat threadsafe counter, kam se musim podivat pred tim, nez locknu na wait - pokud je counter vetsi nez nula, dekrementuju, necekam, zpracovavam frontu, pokud je nula, blokuju na wait - producent opacne (pri pridavani do fronty inkrementuje counter a releasuje wait). Lockovani fronty je dulezity, pokud se sejdou 2 a vice konzumentu najednou a ve fronte je pro ne dost prace. Ta druha vopicarna (counter a wait) je kvuli blokovani konzumentu, pokud nemaj co delat (fronta je empty) - blokovani producenta je out of scope tohohle zadani, protoze buh vi odkad ten co produkuje (treba neblokuje vubec a bezi v nekonecny smycce na max rychlosti). Pokud nekdo vi jedno primitivum, ktery vyresi ty waity bez countru (teda ma ten counter v sobe) tak sem s nim.

SLUPKA: Vzhledem k tomu, ze jen obaloval obycejnou queue, tak si se semaforama nijak nepomuzes. Oboje dvoje operace jsou zapisovaci a menej stav, takze potrebujes vsechny ostatni vlakna zastavit.
Jina situace uz je u metody Peek() - ta je ciste cteci. V tu chvili by byly k necemu dobry. Ale na druhou stranu v .NETu existuje trida ReaderWriterLockSlim, ktera tohle umi resit docela pohodlne.

A to cele samozrejme neni vsechno. Ten "lock(x) { ... }" ma velkou vyhodu v tom, ze to je syntax-suger s Monitor.Enter(), Monitor.Exit() a to spolecne s "try { ... } finally { ... }". Takze neocekavana vyjimka to cely nerozbije.

Ovsem to stale neni odolne proti situaci kdy nejaky "chytrak" zavola Thread.Abort() na dotycnem vlakne (z jineho vlakna samozrejme). Protoze ten syntax sugar je v poradi:
1) Enter
2) Try
2.1) ... body ...
3) Finally
3.1) Exit

Takze kdyz se vyhozeni ty ThreadAbortException trefi mezi 1. a 2. bod, stale se to muze rozbit. (Samozreme volani Thread.Abort() na jinem vlakne nez na vlastnim je prasarna a dokonce to ani nezarucuje, ze ten thread skonci.)

Kdyz uz jsme teda u toho, nedavno jsem se tu ptal na codereview my extension metody, ktera by tohle vsechno mela resit. Tak jestli bych mohl poprosit tebe - koukni na to: http://codereview.stackexchange.com/questions/18908/extension-methods-for-readerwriterlockslim

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