ist Queue.Synchronized schneller als mit einem Lock ()?

Wenn Sie Queue.Synchonized anfordern, erhalten Sie eine SynchronizedQueue , die lock sehr minimal bei Aufrufen von Enqueue und Dequeue in einer inneren Warteschlange verwendet. Daher sollte die Leistung dieselbe sein wie die Verwendung von Queue und die Verwaltung der Sperrung für Enqueue und Dequeue mit Ihrer eigenen lock .

Sie stellen sich tatsächlich Dinge vor - sie sollten gleich sein.

Aktualisieren

Es gibt tatsächlich die Tatsache, dass Sie bei Verwendung von SynchronizedQueue eine indirekte Ebene hinzufügen, da Sie die Wrappermethoden durchlaufen müssen, um zu der inneren Warteschlange zu gelangen, die sie verwaltet. Wenn überhaupt, sollte dies die Dinge nur sehr langsam verlangsamen, da Sie einen zusätzlichen Frame auf dem Stack haben, der für jeden Anruf verwaltet werden muss. Gott weiß, ob das In-Lining dies aufhebt. Was auch immer - es ist minimal .

Update 2

Ich habe das jetzt getestet und wie in meinem vorherigen Update vorhergesagt:

  

"Queue.Synchronized" ist langsamer als "Queue + lock"

Ich habe einen single-threaded-Test durchgeführt, da beide die gleiche Locking-Technik verwenden (d. h. lock ), so dass der reine Overhead in einer "geraden Linie" vernünftig erscheint.

Meine Benchmark hat die folgenden Ergebnisse für eine Version erstellt:

Verwenden Sie den folgenden Code:

Wir können das nicht für Sie beantworten. Nur Sie können es selbst beantworten, indem Sie einen Profiler erhalten und beide Szenarien ( Queue.Synchronized vs. Lock ) auf realen Daten Ihrer Anwendung testen. Es kann nicht einmal ein Flaschenhals in Ihrer Anwendung sein.

Das heißt, Sie sollten wahrscheinlich nur ConcurrentQueue verwenden.

1. Queue.Synchronize Wraps einer neuen Queue Synchronisiert, während Lock Queue.SyncRoot einem Objekt den Zugriff auf den synchronisierten Queue-Weg gewährt. Auf diese Weise können Sie Thread Safety in der Queue sicherstellen, während Sie die Operationen Enqueue und Dequeue gleichzeitig mit Threads verwenden.