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

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 :)

P19: to by me zajimalo, na co se musis takhle ucit nemyslny detaily, tohle bych vyresil za par minut s pomoci google (a to sem to v zivote nevidel), prijde mi nesmysl, ze nekdo pozaduje na pohovoru neco takovyho.
nicmene na tvoji otazku. ja sem nasel na googlu tohle
System.Collections.Concurrent Namespace ()
http://msdn.microsoft.com/en-us/library/system.collections.concurrent.aspx
jsou to implementace primo v netu pro thread safe kolekce (mezi nimi je i quene.
ale protoze jsem to nikdy nepotreboval nevim, zda je to best praktices.

Zdravím,

připravuju se na pohovor a našel jsem úlohu v C#:
mám semaphor a queue (nesmím použít žádnou 3rd party library). Mám napsat thread-safe queue, ke které přistupuje několik vláken, které do fronty vkládají a ostatní vlákna z fronty vybírají. Těch co z fronty čtou je o poznání více než těch, co do ní vkládají. Rychlost je hlavní kritérium (jak jinak :D).

Jako pravověrný webař v tom popravdě hodně plavu, napsal jsem tohle, ale nechce se mi věřit, že by to bylo ono, tak jednoduchý:

public void Enqueue(object obj)
{
_semaphore.WaitOne();
_queue.Enqueue(obj);
_semaphore.Release();
}

public object Dequeue()
{
object obj = null;
_semaphore.WaitOne();
obj = _queue.Dequeue();
_semaphore.Release();
return obj;
}
Můžete mě prosím někdo nakopnout správným směrem?

Díky moc

ALIK: To jo. Ale kdyz vemu ten svuj managed kod a zkopiruju ho u projektu WPF do projeku Store, tak mi to v zasade pobezi. Maximalne s nejakejma drobnejma upravama.

TENCOKACISTROMY: Ne, WPF a WinRT má společné jen to, že podporují jazyk XAML (který lidi znají ze Silverlight a WPF, nicméně i u něj se implementace odlišují) pro definici vzhledu a .NET jako "jazyk". Vše ostatní je jiné. Zatímco WPF je implementováno jako nadstavba, WinRT je nativní Win API. Jedná se o další implementaci toho samého, na co je poslední dobou MS odborník - WPF, Silverlight, WinRT sice vypadají, že jsou si podobné, ale jedná se o zcela jinou implementaci (skoro) téhož.

tak ja vsechny kontroly zatim kreslim primo v kodu pomoci drawing context, xaml je pouzit akorat pri nanaseni kontrolu na plochu, ale tam bude casem designer a taky se to bude delat v kodu.

TENCOKACISTROMY: Tak jsem to aspon pochopil.

ALIK: Prave proto mas pouzit WPF - to je "nativni" zpusob jak tam delat UI.

ALIK: Jestli se pro nej rozhodnes (ostatne proc ne, kdyz ti bude stacit), tak nam tu dej vedet jaka s tim byla zkusenost.

TENCOKACISTROMY: Já narážel i na UI. Neboť se jedná o zcela nezávislou separátní implementaci a z WinRT nelze z UI tuším použít nic, co není založeno na WinRT, beru jako reálné riziko, že vizuální WPF komponenty nebudou kompatibilní s RT verzemi.

TENCOKACISTROMY: Jsem si vědom toho, že na Access posledních cca deset let nešáhli a že je na něm vidět, že není vlajkovou lodí, takže se místy chová dosti neohrabaně a z pohledu uživatele nepřívětivě. Dále, že jeho použití je "rozumné" pouze do chvíle, do kdy si projekt vystačí se základním chováním, tj. bez potřeby maker. U zákazníků bez hrozícího potenciálu růstu (dle počtu uživatelů, počítačů a složitosti databáze) to nabízím jako alternativu k plnohodnotné implementaci. Neboť se na trhu vyskytl nový LightSwitch, který na první pohled vykazoval potenciál, vzal jsem ho do úvahy a v rámci ní se obrátil i zde na vás. Díky za názory.

ALIK: V obecnem pripade ne, ale pokud nepouzivas zadny unmanaged zalezitosti, tak neni v zasade zadna prekazka k tomu, aby to nejelo. S tim unamanged mam samozrejme na mysli, ze to nesmi pouzivat ani referencovany assembly apod...

S kompatibilitou s WinRT bych v obecném případě nebyl úplně optimistický, jedná se o zcela oddělenou implementaci. Nicméně aktuální Portable Class Library ve VS 2013 má pro ".NET for Windows Stores" zaškrtávátko.

TENCOKACISTROMY: to si me potesil :)

ALIK: Proti accessu nic nemam, ale ten vyvijeli 10 let, nez vydali verejnou verzi. Pak to dalsich deset let uspesne vylepsovali a byl to sveho casu asi nejlepsi RAD nastroj pro datacentricky aplikace. Od verze XP dal to s nim jde ale z kopce.

Pokud jeho schopnosti staci na tvuj projekt, klidne ho pouzij.

tck: jak je to vubec s portaci na WinRt
delam ted jistou multitouch aplikaci ve wpf, a chtel bych to pak casem mit na tabletech, protoze tam to skutecne ma smysl a samozrejme ty s winrt jsou levnejsi. tak jestli to pude nejak snadno. nepouziva to zadny databaze, je to jen xaml a samozrejme c# ale nic specialniho.

WinForms neuvažuji. Pokud hrubou sílu, tak WPF.

urcite doporucuju vysrat se na winformy, to nema zadnou budoucnost

mimochodem mrkni na tohle
patterns & practices: Prism - Home
http://compositewpf.codeplex.com/

Low Cost jsem myslel třeba "naklikání" v Accessu s tím, že pokud na to nasadí více lidí či si začne vymýšlet, tak tu částku "odepíše" jako náklad na prototyp. Mám několik zákazníků, kteří jsou s naklikáním v Accessu již několik let spokojeni.

Na druhou stranu, zákazník s obratem 50 tisíc měsíčně těžko kývne na řešení na 200 tisíc (čísla jsou jen ilustrační a nemají s diskutovaným zadáním žádnou souvislost). Náklady, se kterými přijdu, prostě musí být přiměřené jeho možnostem.