Laden...

Queue .NET 2.0 - reicht ein Lock?

Erstellt von inflames2k vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.921 Views
inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 13 Jahren
Queue .NET 2.0 - reicht ein Lock?

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 |

P
992 Beiträge seit 2007
vor 13 Jahren

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
}

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 13 Jahren

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 |

C
401 Beiträge seit 2007
vor 13 Jahren

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...

N
203 Beiträge seit 2008
vor 13 Jahren

Gibt auch noch die Lockfreie Queue von Floste.

Signatur.Text = "Greetz, Neals";

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 13 Jahren

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 |

771 Beiträge seit 2009
vor 13 Jahren

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....

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 13 Jahren

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 |

49.485 Beiträge seit 2005
vor 13 Jahren

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

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 13 Jahren

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 |