Kādi problēmas var rasties, strādājot ar daudzvītņu programmēšanu, un kā no tām izvairīties?

Problēmas daudzprocesu darbā un to izvairīšanās veidi:

• Datu sacīkstes (Data Race): rodas, kad vairāki pavedieni vienlaikus piekļūst kopīgiem datiem, un vismaz viens pavedienis šos datus modificē. Tas var novest pie nenoteiktas uzvedības un nepareiziem rezultātiem.

  • Risinājums: izmantot sinhronizācijas mehānismus, piemēram, lock (Monitor), Mutex, Semaphore, ReaderWriterLockSlim, SpinLock.

  // Piemērs ar lock
  private object _lockObject = new object();
  private int _counter = 0;
  
  public void Increment()
  {
      lock (_lockObject)
      {
          _counter++; // Kritiskā sekcija
      }
  }
  

• Vietējā bloķēšana (Deadlock): notiek, kad divi vai vairāki pavedieni ir bloķēti, gaidot resursus, kurus tur cits pavediens.

  • Risinājums:
    • izvairīties no iekļautas bloķēšanas.
    • bloķēšanas iegūšanu veikt iepriekš noteiktā secībā.
    • izmantot Monitor.TryEnter vai Mutex.WaitOne(timeout) mēģinājumam iegūt bloķēšanu ar laika ierobežojumu.

• Badāšana (Starvation): situācija, kad viens vai vairāki pavedieni ilgstoši nevar piekļūt nepieciešamajiem resursiem (piemēram, bloķēšanai) tāpēc, ka citi pavedieni tos pastāvīgi izmanto.

  • Risinājums:
    • izmantot taisnīgus (fair) sinhronizācijas mehānismus (ne visi standarta mehānismi garantē taisnīgumu).
    • pārskatīt dizainu, iespējams, sadalīt lielas kritiskās sekcijas.
    • izmantot pavedienu baseinus ar pareizu prioritāšu pārvaldību (lai gan prioritāšu maiņa var radīt citas problēmas).

• Nepareiza objekta publicēšana (Improper Publication): stāvoklis, kad objekts kļūst pieejams citiem pavedieniem pirms tā pilnīgas konstrukcijas vai pirms visu tā lauku pareizas inicializācijas.

  • Risinājums:
    • izmantot nemainām (immutable) objektus.
    • izmantot kavēto inicializāciju ar drošiem pavedienu mehānismiem (Lazy<T>).
    • izmantot sinhronizāciju pirmās publicēšanas laikā.

• Neredzamās izmaiņas (Visibility Issues): izmaiņas, ko veicis viens pavedienis, var nebūt redzamas citiem pavedieniem nekavējoties, jo ir procesora kešatmiņa vai kompilatora optimizācijas.

  • Risinājums:
    • izmantot atslēgvārdu volatile mainīgajiem, kuriem piekļūst daudzi pavedieni (nodrošina, ka lasījums vienmēr tiek ņemts no atmiņas, bet ieraksts tiek atjaunināts atmiņā).
    • izmantot sinhronizācijas mehānismus (lock, Monitor), kas ietver atmiņas barjeras.

  // Piemērs ar volatile
  private volatile bool _stopRequested = false;
  
  public void WorkerMethod()
  {
      while (!_stopRequested)
      {
          // Veicam darbu
      }
  }
  
  public void RequestStop()
  {
      _stopRequested = true;
  }
  

Problēmu un risinājumu tabula:

Problēma	Apraksts	Risinājums
Datu sacīkstes	Vienlaicīga pieeja kopīgiem mainīgiem datiem.	lock, Mutex, Semaphore, ReaderWriterLockSlim, SpinLock.
Vietējā bloķēšana	Pavedieni gaida resursus, kurus tur citi.	Izvairīties no iekļautas, pareizi iegūt bloķēšanu, izmantot laika ierobežojumus.
Badāšana	Pavediens nevar iegūt piekļuvi resursam ilgā laika periodā.	Taisnīgi sinhronizācijas mehānismi, dizaina pārskatīšana, prioritāšu pārvaldība (uzmanīgi).
Nepareiza publikācija	Objekta pieejamība pirms pilnīgas inicializācijas.	Nemaināmi objekti, Lazy<T>, sinhronizācija publikācijas laikā.
Neredzamās izmaiņas	Izmaiņas, ko veicis viens pavedienis, nav redzamas citiem.	volatile, atmiņas barjeras (paredzētas sinhronizācijas mehānismos).

Turklāt ir svarīgi izmantot augstākā līmeņa abstrakcijas, piemēram, Task Parallel Library (TPL) un async/await. Tie vienkāršo paralēlismu un asinhrono vadību, samazinot šo problēmu rašanās risku, pareizi izmantojot.