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.

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.