dotNETportal.cz

Chci se zeptat, zda řešit načítání dat z ext. zařízení a zobrazování v grafu takto:

A) První vlákno čte pomocí socketů data a ukládá do List<>

B) Druhé vlákno načítá data z listu, zpracuje a zobrazí do grafu

Mám použít metodu synchronizace "producent-konzument" se společnými daty v seznamu?

Je lepší zamykat list lock(list) nebo lock(nejakyJinyObject) ?

díky moc za každou radu

To zobrazování má probíhat v reálném čase? Jak často probíhá zapisování dat do seznamu?

Zobrazování bych samozřejmě, co nejrychlejší:-) Rychlost čtení ze zařízení (a zápis do seznamu) je asi 10-20x za sekundu (odhad, neměřil jsem to.)

V tom případě to bude drhnout při překreslování v UI. Čtení ze zařízení samozřejmě provádět ve vlastním vlákně a překreslování na Timer např. jednou za pět vteřin. Ohledně synchronizace bych doporučoval vytvořit vlastní synchronizovanou kolekci, inspirovat se můžete mým thread-safe slovníkem (dělal jsem ho už dávno a je to první verze, možná tam budou nějaké chyby).

http://www.vbnet.cz/snippet--68-synchron...

díky za radu, zkusím se tím prokousat (VB není můj šálek kávy:-)

Tohle je v .NET Frameworku vyřešené. Nedoporučuju psát vlastní řešení, pokud nemáte nějaké zvláštní požadavky.

Kolekce pro konkureční prostředí jsou v namespacu:

http://msdn.microsoft.com/en-us/library/...

Konkrétně vás bude zajímat fronta pro použití z více vláken:

http://msdn.microsoft.com/en-us/library/...

Samozřejmě ji můžete používat v kombinaci s dalšími synchronizačními primitivy, pokud bude potřeba například o nových datech notifikovat a nekontrolovat je průběžně.

Vida, to jsem ani nevěděl. Novinky ve Frameworku 4.0 teprve vstřebávám, protože ze 3.5 jsem přešel nedávno.

Mohu to tedy použít takto bez dalších synchronizačních prvků?

class ItemClass
{
  string Name;
  object Value;
}

ConcurrentQueue<ItemClass[]> q;

Vlakno A: načítání (co nejrychlejší)
ItemClass[] tempA = seznam dat z jednoho čtecího příkazu 
q.Enqueue(tempA)

Vlakno B: zobrazuji (pomalejší než Vlákno A)
ItemClass[] tempB;
q.TryDequeue(out tempB)
graf.Invoke(zobrazData)

Ano. Pokud již nebudete po vložení do fronty objekt z vlákna A modifikovat.

Ještě bych kód upravil na kontrolu, zde se nějaká data podaří získat. Například:

if(q.TryDequeue(out tempB))
{
    graf.Invoke(zobrazData)
}

Místo třídy použijte strukturu, bude to rychlejší.

Cim to tvrzeni podlozite? Pri poctu cca 15/s je celkem jedno, co se pouzije. Zvlast, kdyz se data pak budou nasledne vykreslovat.

Jak bylo zmíněno, tak struktura je hodnotový typ. Tudíž režie na vytvoření je menší než u třídy. Nevím jaké povahy je zařízení a jak je udělaný komunikační protokol. Autor požaduje, aby to bylo co nejrychlejší, frekvence 20Hz se mi zdá dost málo (nicméně teoreticky může být přenos v 10 KB/s), ale autor uvedl, že je to jen odhad. Ano při práci se strukturami je třeba si plně uvědomit, že uchovávám přímo hodnoty a nikoli ukazatele na pamět. Znát význam ref a out je zde žádoucí. Pokud vlákno, které zpracovává data, má za 1s vytvořit 10k instancí tříd, není to příliš rychlé. Při zobrazování přes timer 15/s tam je to opravdu jedno, pokud mi nejde o real time.

Nechci aby to pusobilo urazlive, ale vim, jaky je rozdil ve vykonu trid a struktur. A prave proto jsem napsal, at nejak podlozite vase striktni tvrzeni "Pouzijte strukturu misto trid, bude to rychlejsi". Vy jste misto toho nabidnul relevantni vysvetleni, jehoz zaverem je minimalne rozsireni onoho puvodniho tvrzeni na: "Zvazte pouziti struktur misto trid, ktere bude znatelne rychlejsi, pokud systemem protece cca 1000x vice dat, nez jste uvedl jako odhad."

V pripade, kdy by ale systemem teklo o tolik vice dat, hledal bych optimalizace na mnoha jinych mistech.

Pouze jsem chtel upozornit na v tuto chvili zbytecnou mikrooptimalizaci.

Omlouvam se za absence diakritiky.

Ano máte pravdu, že tvrzení: Místo třídy použijte strukturu, bude to rychlejší, bylo výkřikem do tmy, bez konkrétního vysvětlení. V popsaném případě by rozdíl nebyl prakticky vůbec patrný (při 20 Hz). Bohužel většina programátorů tento rozdíl ani nezná a používá třídy tam, kde by bylo vhodnější použít struktury.

S tim se neda nez souhlasit. Druhym extremem pak jsou "akademici", kteri travi zbytecnou mikrooptimalizaci spoustu casu a ve vysledku kodu spis uskodi jeho zeslozitenim s nulovym prinosem. Chce to mit znalosti a pouzivat pri jejich aplikaci hlavu.

To máte určitě pravdu. Někdo je zastáncem: udělat to co nejrychleji a funkčně a když nebude někomu něco vyhovovat, tak se to optimalizuje dle potřeby. Tento přístup je většinou správný, ale už párkrát se mi vymstil, hlavně u aplikací, kde bylo třeba něco často měnit a rozšiřovat, bohužel toto na začátku vývoje většinou netušíte a požadavky vyplynou až časem, proto jsem třeba já zastáncem udělat návrh aplikace tak, aby byl robustnější než je vlastně potřeba. To už jsem ale úplně odbočil a hlavně si myslím, že vy jste ten poslední komu bych to musel vysvětlovat.

Navíc struktura je hodnotový a ne referenční typ a pro někoho kdo si při použití plně neuvědomuje všechny důsledky to může způsobovat naprosto nečekané chování.