[C#] Parallel lezen en schrijven van gedeelde resource

[jelmervos]

Ik heb een class die door verschillende threads zeer veel gebruikt wordt. Het is van belang dat dit zo snel mogelijk gaat en dat methodes zoveel mogelijk parallel uitgevoerd kunnen worden.
Nou bevat deze class een resource welke gedeeld wordt door de methodes, bijvoorbeeld een bestand. Ik heb twee methodes die deze resource alleen lezen en 1 methode die de resource leest en schrijft:

code:

public class MijnKlasse
{
  public void DoeLeesActie1
  {
    //Gebruik gedeelde resource om te lezen
  }

  public void DoeLeesActie2
  {
    //Gebruik ook gedeelde resource om te lezen
  }

  public void DoeLeesEnSchrijfActie
  {
    //Gebruik gedeelde resource om te lezen en te schrijven
  }
}

Ik wil dat DoeLeesActie1 en DoeLeesActie2 parallel te gebruiken is door verschillende threads. Maar als DoeLeesEnSchrijfActie wordt uitgevoerd moeten de lees-acties wachten. Wordt er 1 van de 2 lees-acties uitgevoerd (of beide) dan moet de lees-en-schrijf-actie wachten.

Hoe los ik dit het beste op?

[MTWZZ]

Lees je eens in over het gebruik van locks en mutexen.
Met die mechanismen kun je acties thread safe maken en zorgen dat je threads wachten wanneer een resource in gebruik is.

Zie ook het voorbeeld op MSDN

[ Voor 24% gewijzigd door MTWZZ op 08-02-2010 11:18 ]

[whoami]

Kan je geen Mutex gebruiken.
DoeLeesEnSchrijfActie 'zet' de Mutex.
DoeLeesActie1 kan alleen maar lezen als de Mutex vrij is
DoeLeesActie2 kan ook alleen maar lezen als de Mutex vrij is.

[Janoz]

whoami schreef op maandag 08 februari 2010 @ 11:17:
Kan je geen Mutex gebruiken.
DoeLeesEnSchrijfActie 'zet' de Mutex.
DoeLeesActie1 kan alleen maar lezen als de Mutex vrij is
DoeLeesActie2 kan ook alleen maar lezen als de Mutex vrij is.

Maar dan heb je nog niet afgedekt dat "DoeLeesEnSchrijf" niet mag starten wanneer "DoeLeesX" bezig is.

[whoami]

Janoz schreef op maandag 08 februari 2010 @ 11:21:
[...]

Maar dan heb je nog niet afgedekt dat "DoeLeesEnSchrijf" niet mag starten wanneer "DoeLeesX" bezig is.

Ah, ok, daar had ik over gelezen.
Nuja, ook voor dat blijft het principe 't zelfde natuurlijk, maar dan omgekeerd.

[ Voor 3% gewijzigd door whoami op 08-02-2010 11:23 ]

[jelmervos]

MTWZZ schreef op maandag 08 februari 2010 @ 11:16:
Lees je eens in over het gebruik van locks en mutexen.
Met die mechanismen kun je acties thread safe maken en zorgen dat je threads wachten wanneer een resource in gebruik is.

Zie ook het voorbeeld op MSDN

Ik heb daar al naar gekeken en gebruik nu lock, alleen dat is teveel van het goede. Het kan sneller doordat DoeLeesActie1 en DoeLeesActie2 prima parallel kunnen worden uitgevoerd. Als ik alles afdek met 1 lock dan moeten ze steeds wachten en dat is zonde.

[Janoz]

Locks zijn hier dan ook niet de oplossing. Mutexen zullen beter werken. Whoami's oplossing is al op de helft.

[MTWZZ]

Meer locks gebruiken dus, want zoals whoami en Janoz al opmerken met 1 kom je er niet.

[jelmervos]

Janoz schreef op maandag 08 februari 2010 @ 11:28:
Locks zijn hier dan ook niet de oplossing. Mutexen zullen beter werken. Whoami's oplossing is al op de helft.

Ik ga het proberen met 2 mutexen, bedankt!
Aangezien ik zeker wil zijn dat dit goed gaat werken post ik straks toch even mijn oplossing om te controleren. Ik wil straks namelijk geen vage fouten in de productieomgeving.

[Janoz]

@MTWZZ: Ik zeg helemaal niet dat je meer locks moet gebruiken, maar dat je mutexen moet gebruiken .

@jelmervos: Zulke multithreading issues zijn inderdaad erg nasty. Vooral omdat ze zo moeilijk te testen zijn en bugs eigenlijk nauwelijks (consequent) te reproduceren zijn.

[jelmervos]

Ik loop nu pas tegen de ReaderWriterLockSlim aan:

Represents a lock that is used to manage access to a resource, allowing multiple threads for reading or exclusive access for writing.

Is dat niet precies wat ik nodig heb?

Heb even verder gekeken, en het lijkt erop dat de writer lock ook pas wordt opgeheven als alle readers klaar zijn.

[ Voor 15% gewijzigd door jelmervos op 08-02-2010 11:51 ]

[djexplo]

jelmervos schreef op maandag 08 februari 2010 @ 11:49:
Ik loop nu pas tegen de ReaderWriterLockSlim aan:
...

Is inderdaad een handige functie, die alle read en write acties tegen houd zolang er een thread aan het schrijven is. Dus daardoor krijg je nooit half geschreven informatie terug, of andere problemen.

[jelmervos]

Ik denk dat ik die maar ga gebruiken, ga niet 2x het wiel uitvinden. Bedankt voor het meedenken!

[ Voor 17% gewijzigd door jelmervos op 08-02-2010 11:59 ]