Este necesară blocarea citirii și scriere pentru acest caz de utilizare

Întrebarea mea este similară cu acest thread , totuși sunt sigur că concluzia trasată în firul dat se aplică aici.

Cazul meu de utilizare: În aplicație, există un fir de stare care transmite aceleași informații text după fiecare 1 secundă. Informațiile textuale conțin numele grupului de aplicație. Această stare este utilizată de cititorul de stare pentru a determina dacă serverul de aplicații este pornit/oprit.

Acum, numele grupului de aplicație se poate schimba în timpul vieții sale. Se asigură că numai firul unic din aplicație declanșează acest eveniment din cauza unei anumite activități de utilizator. Acum, acest singur fir are noul nume al grupului de aplicații pe care trebuie să îl actualizez la firul meu de stare.

Implementarea mea actuală este după cum urmează

  1. Status Thread Main() Take ReadLock Read the application group name Release the ReadLock

    send the status

  2. Updater Thread Main() Taken write Lock Update the group name Release the WriteLock

Cu toate acestea, datorită numărului mare de actualizări care trebuie trimise, mă tem că aș putea introduce degradarea performanțelor pentru încărcături grele. Deci, lucrez la implementarea ulterioară, dar nu sunt sigur dacă acest lucru ar funcționa.

Noua implementare propusă este

  1. Fișierul Sender posedă char * ptr, char [1024] primaryData, char [1024] secondaryData.
  2. Când se pornește prima aplicație, numele grupului este actualizat în primData și ptr indică primarData.
  3. Ori de câte ori firul de actualizare are un eveniment de actualizare, acesta va fi Verificați dacă (ptr == primaryData)     Copiați numele aplicației noi în secțiunea secundară         ptr = date secundare altfel     Copiați numele aplicației noi în primData.     ptr = primarData </​​li>
  4. Starea de stare va folosi întotdeauna datele indicate de ptr pentru a trimite starea. Status Thread va primi în cele din urmă ptr actualizat (având în vedere coerența cache-ului) și va începe să transmită date noi.

Câteva puncte care trebuie luate în considerare aici. 1. Este în regulă, chiar dacă noile date nu sunt disponibile instantaneu în fișierul Stare 2. Nu vreau crash de program din cauza accesului nevalid la memorie.

Prieteni, poți să-mi spui dacă logica de mai sus mă va ajuta să evit blocarea de citire și scriere.

0
@pwny sunt de acord. Dar chiar și în timpul testului de sarcină, nu aș putea genera sarcină reală de calitate a producției. Așadar, vreau să evit codarea optimizată ..
adăugat autor Amey Jah, sursa
@AmeyJah: Atunci testarea încărcării este eronată. Ar trebui să fie capabil să producă încărcări mai mari decât orice pe care probabil veți vedea în producție.
adăugat autor NPE, sursa
Ar trebui să începeți cu implementarea actuală și să optimizați după ce observați degradarea performanței. Optimizarea prematura este (aproape) mereu un lucru rau :)
adăugat autor Anthony Vallée-Dubois, sursa

2 răspunsuri

Blocarea citirii și scrierii într-un scenariu cu un singur cititor și un singur scriitor nu este diferit de un mutex simplu vechi. Doar folosiți un mutex.

0
adăugat

ați putea să-mi spuneți dacă logica de mai sus mi-ar ajuta să evit blocarea de citire și scriere.

Nu, această logică nu vă va lăsa să evitați blocarea. Schema propusă este plină de condiții de rasă.

Sfatul meu ar fi să folosiți un singur matrice char și un singur mutex împărțit de firele de stare și actualizare. Acest lucru va duce la o logică foarte simplă, care va fi ușor de obținut.

Dacă - și numai dacă - se dovedește că acest lucru duce la o inacceptabilă criptare de blocare, ar trebui să luați în considerare optimizarea în continuare.

0
adăugat
Mulțumesc aix, îți dau rostul
adăugat autor Amey Jah, sursa