Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Queue .NET 2.0 - reicht ein Lock?
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2.295

Themenstarter:

Queue .NET 2.0 - reicht ein Lock?

beantworten | zitieren | melden

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 | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers
punkdevil
myCSharp.de - Member



Dabei seit:
Beiträge: 992

beantworten | zitieren | melden

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
}
private Nachricht | Beiträge des Benutzers
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2.295

Themenstarter:

beantworten | zitieren | melden

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 | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers
Corpsegrinder
myCSharp.de - Member



Dabei seit:
Beiträge: 401

beantworten | zitieren | melden

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...
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Corpsegrinder am .
private Nachricht | Beiträge des Benutzers
Neals
myCSharp.de - Member



Dabei seit:
Beiträge: 203
Herkunft: Nordseeküste

beantworten | zitieren | melden

Gibt auch noch die Lockfreie Queue von Floste.
Signatur.Text = "Greetz, Neals";
private Nachricht | Beiträge des Benutzers
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2.295

Themenstarter:

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von inflames2k am .
Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers
Cat
myCSharp.de - Member

Avatar #avatar-3070.jpg


Dabei seit:
Beiträge: 771

beantworten | zitieren | melden

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....
private Nachricht | Beiträge des Benutzers
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2.295

Themenstarter:

beantworten | zitieren | melden

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. :-)
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von inflames2k am .
Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

Hallo inflames2k,
Zitat
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
private Nachricht | Beiträge des Benutzers
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2.295

Themenstarter:

beantworten | zitieren | melden

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 | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers