mausekeks schrieb:

lock (((ICollection)this.messageQueue).SyncRoot)

Wieso nimmst du keine ConcurrentQueue?

Datenstrukturen des Concurrent-Namespaces sind Thread sicher, d.h. es können mehrere Threads auf das Objekt zugreifen, ohne dass es zu ungewolltem Verhalten kommt

Eine Frage die du dir Stellen könntest ist: Wie relevant ist allokationen vs echtzeit(nicht wirklich echtzeit aber trotzdem eine gewisse vorhersehbarkeit, die z.B. bei Spielen benötigt wird) vs start delay?

Allokations bedingt sind die Concurrent Implementierungen schlecht, da diese eine LinkedList verwenden. D.h. für Dinge, die nicht plötzlich den GC haben sollten nicht zu empfehlen(also nicht für Spiele)...
Vorteil dieser ist jedoch dass weniger locking stattfindet und eher teils busy waiting(SpinWait z.B.) was den start delay sehr niedrig hält...

Dein Code oben ist aus branching Sicht auch nicht gerade optimal. switch sollte ebenfalls nicht für bools verwendet werden, wird zwar evtl. vom JITC entsprechend optimiert trotzdem mMn auch schlechter lesbar.

ist wesentlich lesbarer, du sparst dir einen branch, einen else part und eine variable, und noch ein compare^^
Eine weiter Überlegung wäre evtl auch dies hier zu machen:

Abhängig davon wie teuer das verarbeiten einer solchen USB message ist, könnte dies sinnvoll sein, da man wesentlich weniger locking braucht, ggf auf kosten der parallelität(jenach frequenz der eingehenden messages). Eine weitere Idee wäre dann evtl. maximal 4(variabel) auf einmal zu bearbeiten, oder gar in Abhängigkeit der anderen Threads. Die komplexität steigt, aber jenach Ziel kann eben entsprechend optimiert werden.

Wenn die Reihenfolge der ausgeführten Queue nicht so relevant ist, dann wäre natürlich noch eine Überlegung ob man nicht jedem Handler eine eigene Queue gibt, wobei dann in eine dieser Queues abhängig von der Anzahl der bereits beinhalteten Elemente eingefügt wird(umso weniger Elemente um so eher wird eingefügt). Ein Vorteil davon wäre, dass man weiß, dass immer nur ein Thread probiert zu lesen und man darauf entsprechend optimieren kann und anstelle von locking über atomarische Operationen(Interlocked) arbeiten könnte und eine eigens optimierte Queue dafür schreiben...

Aber am Ende braucht solch starken Optimierungen sowieso fast niemand, weshalb du mit entweder deiner bereits vorhanden Lösung(jedoch ohne switch -> s.o.) oder einer ConcurrentQueue ganz gut läufst...


Edit: Tasks sind sowieso noch einmal eine ganz andere Geschichte und werden sowieso über eine Art Threadpool abgearbeitet, was dafür sorgt, dass natürlich das Pooling nicht mehr von dir übernommen werden muss. Task Performance ist dabei jedoch nicht die optimalste, da es dann doch einen gewissen Overhead für die Bequemlichkeit mitgibt. Aber wie bei allem, ist die Frage ob das bisschen Performance für dich relevant ist, oder aber auch wie viel du von der Bequemlichkeit tatsächlich hast und danach wählst du dann das aus, was dir besser gefällt, oder was du brauchst...