Accesul la un fișier INI din mai multe procese
Aplicația gestionează o listă de înregistrări despre obiecte de rețea. Înregistrările pot fi de două tipuri: una este creată automat, deoarece informațiile sunt primite de la rețea ("obișnuit"), altele sunt specificate explicit de utilizator ("obligatoriu"). Informațiile despre obiectele definite de utilizator sunt stocate într-un fișier INI. Toate intrările (atât convenționale cât și obligatorii) sunt vizualizate în UI. Pentru o copie a aplicației totul este simplu: a schimbat setul de înregistrări obligatorii - înregistrat imediat în INIshnik și afișat în interfața de utilizare.
Sarcina este de a permite ca mai multe copii ale aplicației să lucreze împreună. Mai mult, adăugarea / eliminarea înscrierii obligatorii într-o copie a cererii ar trebui să fie luată în toate celelalte. Văd câteva soluții posibile:
1. Creați un fișier mapat în memorie și păstrați acolo o versiune binară a listei de înregistrări.
2. Sincronizați accesul la fișierul INI cu un mutex, înștiințați despre necesitatea de a citi din nou evenimentul.
3. Variații pe tema țevilor sau prizelor.
În timp ce înclinați la numărul de opțiune 2.
Aș dori o opinie de la :)
Se creează un proces separat (server) care gestionează înregistrările (puteți să le acoperiți). Copiile aplicației sunt accesate (prin orice modalitate disponibilă de comunicare între procese) cu serverul.
dar de ce există mai multe procese? mai mult de o copie a aceluiași program?
atunci unde se face mutexul sau mmf?
dacă mai mulți utilizatori lucrează simultan. atunci devine că ei stau la diferite companii.
> Dacă mai mulți utilizatori lucrează în același timp,
> ei stau la diferite companii.
server terminal
> Mă tem că nu vor aproba consumatorii de forță de muncă - mi-e teamă.
Haide - 15 minute de programator de lucru cu depanare. Scuză toate astea.
În general, există o altă opțiune, în codul sursă începem versiunea de câmp. Toți cei care lucrează cu inițiativa (și este protejat de un mutex) ar trebui să crească câmpul versiunii după modificare. Alții recitesc regulat regulat și privesc dacă versiunea sa schimbat, dacă actualizează, actualizează valorile.
pe server acest lucru nu este adevărat
Ei bine, din nou, numărul unu întrebare:
dracu există mai multe procese identice?
ei, care vor crește numărul de nuclee ale protestelor, sau va crește rata de transfer și totul va deveni mai rapid?
+1 la serviciu, dacă este necesar, comunicarea se poate face prin socketuri și poate chiar să facă serviciul pe un alt server (bine, asta e trucul urechilor =))
Depinde de ce conțin aceste surse (informații despre obiectele definite de utilizator) și, de asemenea, în ce mod ar trebui să se rotească sistemul contabil.
Dacă păstrat ceva mare și grav și nu poate depinde de un PC care rulează un „cont“ nu ar trebui să fie legat la PC-ul la toate, sau un număr mare de utilizatori, sau activitatea de „contabilitate“, în jurul valorii de ceas, etc. atunci trebuie să vă înclinați în mod evident la server-server.
Aceasta necesită mai multă muncă în aceeași aplicație
așa că acesta este proiectul primar al mijloacelor de montare a curbei.
dacă este astfel încât există o cerință excesivă de interactivitate cu utilizatorul.
este a lui și trebuie corectată, în loc să angajeze mai mulți oameni pentru a lucra cu programul neeficient.
Domnilor, domnilor! Această aplicație este doar o parte a sistemului. Monitorizează software-ul doar serviciile lansate pe alte computere în rețea. Sistemul include mai multe programmlin. Adăugarea unui altul este opțiunea cea mai extremă.
scriitor
1. Capturați mutexul.
2. Scrieți fișierul.
3. Setați evenimentul.
4. Eliberați mutexul.
cititor
În așteptare:
1. Capturați mutexul.
2. Citiți din fișier.
3. Eliberați mutexul.
Momentul actualizării datelor este urmărit fără probleme. . Ceea ce este confuz este faptul că procesele necesare pentru 3+ Dansurile cu mai multe evenimentul „sau a unui semafor - data si doua: problema este că veți avea nevoie la citirea fișierului de fiecare jumătate de oră din listă pentru a reconstrui - o operațiune foarte costisitoare, deoarece asociate cu apelurile către rețea.Prin urmare, apropo, nu exclud opțiunile 1 și 3: să schimb doar schimbări, dar nu o listă completă.
De fapt, aici am vrut să întreb cum este rezolvată o astfel de sarcină de către alții.
> deci acesta este proiectarea primară a mijloacelor de montare a curbei.
>
> dacă există o cerință excesivă pentru interactivitate
> cu utilizatorul.
> este el și trebuie să fie corectat, în loc să angajeze mai multe
> O persoană care să lucreze cu un program non-afirmativ.
Cred că nu ar trebui să încercați să telepațiți în absența unei predispoziții la acest lucru :)
ai amestecat într-o grămadă de lucruri diferite.
există un singur proces care poate monitoriza ceva.
și dacă aveți nevoie de mai multă muncă, atunci același proces anunță administratorii care ar trebui să utilizeze alte programe care nu necesită o astfel de magie la ureche.
> În INIshniki - vorbind condițional, numele de gazdă și portul. Pentru fiecare
> înregistrări.
acum este deja ini, sau arhitectura nu a fost încă scrisă?
(Am un exemplu de mai sus [20], un serviciu separat de serverul de web, de asemenea, .ini oferă, datele cererilor de program de la ea (pentru http). În programele se pot încărca din fișier .ini (de exemplu, kernel-ul se ocupă de aceste date .ini oferă o clasă obține fișierul de la rețea pe http sau clasă de citit dintr-un fișier)., dar pe server este stocat în toate SQLite, serviciul le dă numai în format corect, este întotdeauna date relevante)
în general, în orice caz, se pare că sistemul tău este proiectat cu o pretenție de inteligență, dar aici o astfel de aplicare a yuris-ului este o fermă colectivă sinceră. trebuie să scapi de el.
> # xA0; [25]
bine și în consecință datele ca atare sunt transferate puțin și software-ul poate funcționa de la orice calculator al întreprinderii (și sub terminalul unul, de asemenea).
> De fapt, aici am vrut să întreb cum o astfel de sarcină
> alții decid.
Am două obiecte de sincronizare când este numit suficient Eveniment?
1. Există computere (servere) în rețea care deservesc alte calculatoare (clienți) în rețea. Aici "mulți la mulți".
2. Este necesar să se monitorizeze cine și cine servește. Pentru aceasta, există o sub-aplicație (monitor) care găsește serverul, comunică cu aceștia și îi solicită informații despre clienții lor. Și aici, "mulți la mulți".
3. Un computer poate fi simultan un server, un client și mai mult pentru a fi monitorizat.
4. Găsirea tuturor serverelor necesită timp, astfel încât să puteți specifica manual locația anumitor servere - această informație este adăugată la fiecare INI de fiecare monitor.
5. Copiile multiple ale monitorului care rulează pe același nod ar trebui să sincronizeze cumva liste de servere specificate explicit.
Ei bine, în general, pentru a lucra cu init (dacă rămâne), este necesar, prin procesul intermediar, asta e tot.
deși poate că am fost dus și am tras vrăbii din tun =)
> Tipul agregatorului va funcționa :)
și într-adevăr, serverele de căutare, de asemenea, poate fi încredințat un astfel de serviciu, cum ar fi un cronometru pentru a face acest lucru, în ciuda că este de a face pentru a găsi :) si va da o listă gata într-un format convenabil (.ini, xml)
Întregul sistem se deplasează istoric în direcția opusă spre p2p. Probabil, este greșit. Acum, serverele se raportează direct monitorului către radiodifuzor. Acest lucru permite oricărui computer să adauge / mutați / eliminați în / din rețeaua / rețeaua - și va trece în mod transparent utilizatorilor. Făcând un sistem centralizat de colectare a unei serii de servere este destul de risipitor, mai ales că serverele specificate explicit sunt doar o superstructură pe un sistem de succes. Deși în p2p se întâmplă prea multe site-uri pentru a fi mai importante?
Iar sarcina explicită a serverelor era să găsească în primul rând aceia care pot servi, dar nu vor primi o datagramă UDP. Routing.
Apoi, următoarea idee: de ce să nu folosiți coada de mesaje Windows? Nu vă faceți griji că aplicația se va prăbuși, lăsând toate celelalte blocate, nu trebuie să așteptați până la terminarea procesării complete.
Reflecții suplimentare și google m-au condus la DDE.
2. Deseori se întâmplă că DDE este depășită. Ce tehnologii mai noi vă permite să trimiteți câteva kilobiți de date la următorul proces, cu o coadă în coadă cu o cheltuială minimă?
3. Anterior, DDE nu a funcționat, la o examinare sumară a arătat că trimiterea unui singur mesaj nu vor face afaceri - și, prin urmare, trebuie să scrie o mulțime de cod. Pot simplifica în cadrul cererii mele?
Hopa, despre PostMessage. Problemele rămase sunt relevante, la fel ca și recomandările privind transferul unei părți de date într-un proces adiacent.
Memorie: 0,84 MB
Timp: 0.145 secunde
Trimiteți-le prietenilor: