Hallo,
in der kommenden Anwendung muss ich eine Queue nutzen, um Operationen abzulegen, auf die ein Thread zugreift. (Genau genommen 2 - einer Enqueue und einer Dequeue)
Reicht es in dem Fall, wenn ich ein Lock auf die Queue mache bevor ich Enqueue bzw. Dequeue ausführe?
Ob die Threadsichere Queue hier aus dem Forum wirklich notwendig wäre, würd ich verneinen.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Du musst dafür sorgen, das Enqueue und Dequeue nicht zur gleichenZeit von mehreren Threads aus aufgerzfen werden. Dazu reicht z.B. ein einfaches
lock(myQueue)
{
//myQueue.Enqueue()/Dequeue
}
Ok, genau darin bestand auch meine Frage. 😃
Hät ja durchaus sein können, dass es da dennoch irgendwo inkosistent sein könnte. - Aber wenn der einfache lock vor Enqueue und Dequeue reicht ist ja alles in Ordnung.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Vorsicht! Das kann zu Deadlocks führen.
Bsp:
Wenn die Queue leer ist wartet Dequeue, bis ein Element verfügbar ist, es kann aber kein Element hinzugefügt werden, weil die Queue noch gelockt ist und der Bereich, der ein Element hinzufügen will wartet, bis die Queue wieder freigegeben wird.
Schau dir einfach mal SyncQueue <T> - Eine praktische Job-Queue an.
Edit: Oh, scheint in .Net doch anders zu sein... der wirft einfach ne Exception, wenn die Queue leer ist...
Naja das Problem dass bei nix gewartet wird hab ich ja soweit nicht.
Im Thread der Dequeue nutzts, arbeite ich sowieso alle Operationen nacheinander ab, solang noch etwas verfügbar ist. - Und auch nur solang, also so lang Count > 0.
// Edit bzgl der Lockfreien Queue, ja die kenne ich auch. - Aber da während ich Dequeue ausführe dies für jeden EIntrag passieren soll, könnte dort soweit ich das überblicke während den Dequeue auch Enqueue ausgeführt werden. -> Zwischen Dequeue Element x und Dequeue Element y. - Oder seh ich das falsch?
Der Fall wäre dann schlecht, da der rest des Threads dann nicht abgearbeitet werden würde, da auch Logeinträge in die Queue geschrieben werden und im Thread geloggt werden.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Hallo "In Flames" Fan -)
du könntest auch die Queue.Synchronized-Methode zum synchronisieren verwenden (dann mußt du selber keine lock-Anweisung verwenden -)
Vor kurzem hatte hier jemand eine ähnlichen Ansatz: http://www.c-sharp-forum.de/viewtopic.php?t=100845 (der dann noch verbessert wurde, bis es wirklich thread-safe geworden ist -)
P.S. Die "Reroute to Remain" höre ich nämlich gerade - "System" ist mein Lieblingssong davon....
Mein Abteilungsleiter machte den Vorschlag eines ReaderWriterLock.
Nun stellt sich mir hier die Frage, reicht es wenn ich die Zugriffe innerhalb des Threads mittels des ReaderWriterLock schütze oder muss ich damit auch Zugriffe von außerhalb absichern?
// Naja ich hör momentan eher Lunar Strain und Subterranean. 😃
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |
Hallo inflames2k,
Ob die Threadsichere Queue hier aus dem Forum wirklich notwendig wäre, würd ich verneinen.
ich vermute mal, du meinst die SyncQueue <T> - Eine praktische Job-Queue. Notwendig ist die natürlich nicht, aber genau für den Fall gemacht, den du beschreibst. Das spräche dafür, sie auch zu verwenden, zumal du dadurch eleganteren Code bekommst, als wenn du selber lockst oder selber ReaderWriterLock verwendest. Es ist sinnvoller eine Klasse zu verwenden, die die Synchronisation schon mitbringt, als die Synchronisation von außen draufzusetzen.
herbivore
Da muss ich dir allerdings recht geben. - ReadWriterLock werd ich allerdings aufgrund von Zugriffen auf ein Dictionary dennoch brauchen.
Aber für die Queue werd ich wohl nun doch auf die SyncQueue ausweichen.
Wissen ist nicht alles. Man muss es auch anwenden können.
PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |