[so] Tema 4; clarificari din anii trecuti

[Maximilian Machedon]

        Am selectat cateva mailuri din anii trecuti (care mi s-au parut mai
relevante). Sper sa scutesc pe cineva de efortul de a cauta raspunsuri la
intrebari... :-D




On Wed, 15 Dec 2004 12:06:49 +0200, George Ciobanu <so at cursuri.cs.pub.ro>
wrote:

> --- Dorin Pena <dorinpena at gmail.com> wrote:
>
>> Salut!
>>
>> Am o intrebare in legatura cu tema 4.
>>
>> Ce trebuie sa se intample daca se trimite cerere pentru un offset
>> si/sau nr de octeti invalid(prea mare)? Tratam cazurile de acest gen
>> sau presupunem ca nu o sa se dea astfel de teste?
>>
>
> Nu voi face teste legate de offset eronat. In cazul in care semnalati
> acest
> lucru prin eroare, veti primi bonus.
>
>
> In cazul read-ului se citeste exact cat e posibil (la fel ca read).
> Write va
> mari lungimea fisierului (exact ca write).







On Tue, 02 Dec 2003 08:35:04 +0200, Octavian PURDILA <so at atlantis.cs.pub.ro>
wrote:

> Quoting Cibu Cristian <cibu.cristian at rdslink.ro>:
>
>> "Serverul trebuie sa se asigure ca thread-urile sunt egal incarcate."
>>
>> Ce inseamna egal incarcate? (nu ma refer la concept). Eu am in minte 2
>> variante dar nu le spun pentru ca nu vreau sa dau idei de enunt. :)
>>
>>
>
> Inseamna ca thread-urile de acelasi tip trebuie sa aiba un numar egal
> de cereri de procesat. La sosirea unei cereri, serverul va verifica care
> din thread-uri are cele mai putine cereri de procesat si va da cererea
> spre
> procesare thread-udului respectiv.
>
> tavi






On Thu, 09 Dec 2004 17:36:47 +0200, George Ciobanu <so at cursuri.cs.pub.ro>
wrote:

> --- Dorin Pena <dorinpena at gmail.com> wrote:
>>  2. Ce se intelege prin incarcarea fiecarui fir de executie? Se poate
>>  ca de un client sa se ocupe mai multe fire, in cazul in care acesta
>>  cere un fisier f mare? Sau fiecare fir trateaza cate un client?
>>  Prima varianta mi se pare foarte complicata, si personal nu am gasit o
>>  solutie inca.
>>
>
> Incarcarea unui fir de executie se refera la numarul de cereri pe care le
> trateaza el in acel moment. (Deci un fir poate trata mai multi clienti).
> Optional pentru bonus, puteti sparge cererile de dimensiuni mari, in mai
> multe
> cereri de dimensiuni mici (dar ele vor fi tratate de acelasi client in
> ordine).
>







On Tue, 21 Dec 2004 03:09:26 +0200, George Ciobanu <so at cursuri.cs.pub.ro>
wrote:

> Salut,
>
> Un fir de executie worker poate sa trateze mai multe cereri I/O, folosind
> operatii asincrone.
>
> Fiecare fir de executie worker trebuie sa aiba asociata o coada de
> cereri in
> careserverul pune noile cereri respectand restrictia de incarcare egala
> (un
> server asigneaza o cerere firului care are cele mai putine cereri in
> curs de
> executie).
>
> Firul preia cererea/cererile din coada lui si se ocupa de ea.
>
> Modalitatea de notificare pentru cereri noi poate fi orice mecanism de
> sincronizare vreti voi. Pentru tipul a, procesul este notificat printr-un
> semnal la  terminarea operatiei I/O pornite, moment in care se notifica
> firul
> de executie care trebuie sa trateze cererea respectiva. Ar fi de dorit ca
> mecanismul de sincronizare pentru cerere noua sa poata fi folosit si
> pentru
> anuntarea unei cereri terminate. In acest caz, trebuie sa aveti grija ca
> functiile folosite sa poata fi folosite in handler-ul de semnal. (Ca
> exemple,
> malloc, si pthread_*, nu pot fi folosite in functiile de tratare a unui
> semnal).
>
> Pentru tipul b, avand in vedere ca mecanismul de asteptare a terminarii
> unei
> cereri este aio_suspend, pentru a anunta existenta unei cereri noi puteti
> folosi  un semnal pentru a intrerupe functia aio_suspend. (Pentru a va
> asigura
> ca semnalul trimis ajunge exact la thread-ul care trebuie notificat
> folositi
> pthread_kill.)
>
>
> La terminarea unei cereri, firul notificat trebuie sa trimita raspunsul
> catre
> client si va folosi in acest scop o noua operatie asincrona (pe socket-ul
> asociat cu clientul respectiv).
>
>
> George
>
> --- simona pencea <s_pencea at yahoo.com> wrote:
>
>> salut.
>> ma intrebam daca se pot da mai multe detalii despre
>> cum face un thread sa trateze simultan mai multi
>> clienti..
>>






On Sat, 12 Feb 2005 21:39:09 +0200, George Adrian Drumea
<so at cursuri.cs.pub.ro> wrote:

> Daca timeoutul e mic nu se apropie de un busy waiting? E ca si cum as
> avea cu while (cond) cu un sleep(x); Iar daca timeoutul e mare... am
> timp de raspuns prost fix in cazul asta... Alta solutie nu e?
>
>> Salut,
>
>> Ai dreptate, dar atata timp cat aio_suspend are un timeout, se
>> introduce doar o eventuala intarziere.
>
>
>> George
>> --- Horia Handoreanu <hhoria at gmail.com> wrote:
>
>>> Salut,
>>> La rezolvarea temei 4, referitor la threadurile de tip b, solutia
>>> propusa este ca fiecare thread sa astepte in aio_suspend terminarea
>>> operatiilor asincrone incepute, iar la sosirea unei noi cereri de la
>>> un client, threadul main da un pthread_kill, care il scoate din
>>> aio_suspend pe threadul de tip b ce urmeaza sa trateze cererea.
>>> Intrebarea mea este ce se intampla daca threadul b respectiv, in
>>> momentul primirii semnalului, nu era in stare de asteptare, in
>>> aio_suspend?
>>> Sa zicem ca inainte sa intru intr-un aio_suspend verific daca am
>>> primit intre timp vreo cerere, dar tot ramane un moment, fix inainte
>>> de instructiunea in care dau aio_suspend (dar dupa ce am verificat
>>> existenta unor cereri noi) cand, daca vine un semnal, nu imi dau
>>> seama.







On Tue, 28 Dec 2004 22:28:42 +0200, Octavian Purdila <so at cursuri.cs.pub.ro>
wrote:

>> Salut,
>> Problema mea este ca detectez o anumita pierdere de semnale de raspuns
>> in cazul threadurilor de tip a. Asta se intampla cand un thread se
>> ocupa de mai multe cereri simultan si destul de rar. Intrebarea mea
>> este: e posibil ca aceste semnale sa se piarda cu adevarat (din
>> documentatie si de pe google asa reiese).
>
> Da, semnalele non-realtime se pot pierde.
>
>
>> Si daca da, cum am putea sa
>> ocolim problema generata, si anume ca anumite transferuri pot sa se
>> blocheze?
>>
>
>
> O solutie ar fi sa folositi semnale real-time pentru notificare
> (pentru mai multe informatii "man 7 signal")
>
>
> tavi








On Sun, 07 Dec 2003 09:50:45 +0200, George Ciobanu <so at atlantis.cs.pub.ro>
wrote:

> Daca toate threadurile cu notificare de tip b au ajuns la
> MAXIMUM_WAIT_OBJECTS poti
> raspunde cu busy
>
> Mihai Iancu <mail2mihai at yahoo.com> wrote:
>
> WaitForMultipleObject are limita la handles de MAXIMUM_WAIT_OBJECTS.
>
> Consideram ca in caz de mai mult de MAXIMUM_WAIT_OBJECT requesturi
> atribuite
> unui thread dam raspuns de too busy sau gasim o alternativa?