[C#] Collection object vs threading

[robertpNL]

Hallo,

Kan iemand mij in het volgende verhelderen.

Een class bevat een (statische) sortedlist (Collection). Deze wordt door verschillende threads gelezen en soms bewerkt. Je begrijpt, dit kan niet asynchroon dus moet dit gesynchroniseerd worden opgelost. Maar ik zie door de bomen het bos niet meer.

Zo kan ik gebruik maken van:
- de Monitor class van System.Threading. Daarmee wordt voorkomen dat bepaalde stukken code tegelijkertijd door verschillende threads worden uitgevoerd. Maar de parameter voor Monitor.Enter/TryEnter is een object en moet (?) de class zijn? En ik begrijp echt niet wat Pulse en Wait voor method zijn. Hoe moet ik de MOnitor zien in mijn situatie met de Sortedlist?

- Dan heb je ook de mogelijkheid om lock statement te gebruiken. In princpe komt dit toch op het zelfde neer als de Monitor class? Of zit daar echt een verschil in. Maar wat moet ik dan locken? De sortedlist, of de property Sortedlist.SyncRoot?

- Want dan kom ik gelijk op het volgende. Ik snap gewoon niet wat de functionaliteit van SyncRoot is. Het maakt een wrapper waarmee ik gesynchroniseerd de sortedlist item op een veilige manier kan aflopen?

- Dan heb je ook nog de mogelijkheid van ReaderWriterLock Class. Ik heb mij daar nog niet in verdiept maar zou dat een oplossing kunnen zijn?

Kortom, hoe moet ik met een SoredList omgaan die door meerdere threads worden bewerken/gelezen zonder conflicten (lezen en de SortedLis wordt tegelijkertijd bewerkt door een thread).

[Alarmnummer]

De meest eenvoudige manier is om een synchronized wrapper om die lijst heen te zetten waarbij iedere methode gesynchroniseerd is. Als deze synchronisatie te zwaar is (kan in sommige situaties) dan kan je kijken naar fijnere methodes en dan kom je bij complexere synchronisatie bouwstenen aan. Verder heb ik bijna nooit meer volledig gesynchroniseerde structuren en geef ik mijn collections eigelijk ook bijna nooit meer uit handen (ze zijn altijd wel onderdeel van een grote structuur en laat ik die verantwoordelijk zijn voor de concurrency control).

Mijn tip op dit moment: kijk of je die hele structuur gesynchroniseerd kan krijgen. Ik durf te wedden dat .net hier wel functionaliteit voor heeft.

[ Voor 23% gewijzigd door Alarmnummer op 02-09-2005 22:22 ]

[mOrPhie]

Alarmnummer schreef op vrijdag 02 september 2005 @ 22:15:
Mijn tip op dit moment: kijk of je die hele structuur gesynchroniseerd kan krijgen. Ik durf te wedden dat .net hier wel functionaliteit voor heeft.

Klopt. De mutex:

http://msdn.microsoft.com...eadingmutexclasstopic.asp

[Alarmnummer]

mOrPhie schreef op vrijdag 02 september 2005 @ 22:23:
[...]
Klopt. De mutex:

Een mutex is een synchronisatie bouwsteen waarmee je de structuur kunt synchroniseren, maar ik durf te wedden dat er kant en klare synchronized wrappers zijn voor de standaard collectie structuren (in java heb je dat bv wel).

[whoami]

Tja, zoals de topicstarter al zei, heeft .NET idd een aantal mogelijkheden om spullen te locken en te synchen:
- Monitor
- lock
en een mutex

Als ik het goed heb, verkrijg je met het lock statement een 'mutex'. Een lock zorgt ervoor dat de resources die binnen het lock statement staan, slechts door 1 thread tegelijk kunnen benaderd worden.

Ik zie in de .NET docs ook, dat een SortedList een Synchronize method heeft.
Deze returned een synchronized SortedList.

To create a synchronized version of the SortedList, use the Synchronized method. However, derived classes can provide their own synchronized version of the SortedList using the SyncRoot property. The synchronizing code must perform operations on the SyncRoot of the SortedList, not directly on the SortedList. This ensures proper operation of collections that are derived from other objects. Specifically, it maintains proper synchronization with other threads that might be simultaneously modifying the SortedList object.

Enumerating through a collection is intrinsically not a thread-safe procedure. Even when a collection is synchronized, other threads could still modify the collection, which causes the enumerator to throw an exception. To guarantee thread safety during enumeration, you can either lock the collection during the entire enumeration or catch the exceptions resulting from changes made by other threads.

In the absence of a Synchronized method on a collection, the expected usage for SyncRoot looks like this:

code:

ICollection MyCollection = ...
lock( MyCollection.SyncRoot ) {
 // Some operation on the collection, which is now thread-safe.
}

Enumerating through a collection is intrinsically not a thread-safe procedure. Even when a collection is synchronized, other threads could still modify the collection, which causes the enumerator to throw an exception. To guarantee thread safety during enumeration, you can either lock the collection during the entire enumeration or catch the exceptions resulting from changes made by other threads.
The following code example shows how to lock the collection using the SyncRoot during the entire enumeration:

code:

ICollection myCollection = new ICollection();
lock( myCollection.SyncRoot ) {
 foreach ( Object item in myCollection ) {
 // Insert your code here.
 }
}