OT - multitask

[Andras Tantos]

Hali!

En a kovetkezot csinalnam: A 'szkop' processz, vagy thread, vagy akarmi 
szepen toltoget egy (cirkularis) buffert. Amikor kesz van vele (pl. mert a 
trigger feltetel teljesult) akkor a buffert 'kesz'-nek nyilvanitja, es uj 
buffert kezd tolteni. Amikor a masik, megjelenito thread-nek az adatokra 
szuksege van, akkor 'mintat' vesz a 'kesz' bufferbol, azaz az egeszet 
gyorsan atveszi maganak, es ezzel egyutt ad egy ujabb buffert a szkop 
thread-nek (feltehetoen azt, amit ez elott vett el). Ez nagyon gyorsan 
megoldhato (2-3 pointer muvelet), erre az idore egyszeruen letiltanam az 
IRQ-kat (ez sokkal gyorsabb, mint egy mutex, vagy valami hasonlo 
szinkronizacios mechanizmus). Ha a megjelenito thread elvette az adatokat 
ilyen modon, utana mar motozhat amilyen sokaig akar. Ez egy megjelenito 
eseten szepen mukodik. Ha ket megjelenito van, akkor talan az a legjobb, ha 
a szkop processz egyszerre ket buffert tolt mindket megjelenitonek. Vegulis 
az otlet nem mas, mint egy '1' melysegu FIFO tarolo, amiben az elemek egesz 
buffer-ek.

Udv,
Tantos Andras



----- Original Message ----- 
From: "Erdos Zoltan" <silverst at axelero.hu>
To: <elektro at tesla.hu>
Sent: Saturday, December 17, 2005 8:49 AM
Subject: Re: OT - multitask


> Hm... gondolkodom...
>
> Alapbol egy nagy puffermemorias tarolo szkopra gondolok, ami a masik felen 
> weboldalon mutatna a jelalakot... azaz webserverkent is muxik.
> az adatallomany raadasul idoben gyorsan valtozo, az egyik process (a 
> mintavet-betarol) irja piszkosul a tarat (adatstrukturat ha ugy progizom) 
> a masik process (ami  mondjuk aktiv html-be agyazott ablak)
> meg olvassa rendesen.... Namost oket hogyan vedjem egymastol?
> Az meg csak a hab a tortan, hogy egy kis lcd-n is megy a megjelenites... 
> :-)
> (meg azon is gondolkodom, konvertalom az egeszet vmi animalt gif-nek, 
> aljas modon atverve az egesz browsert.. :-) )
>
> Z.
>
> SZIGETI Szabolcs wrote:
>
>> Hali!
>>
>> Nem bonyolult, csak de :-)
>>
>> A cache-nek nem sok köze van hozzá direktben. Arra kell vigyázni, hogy a 
>> küönbözo kernel adatstuktúrák védve legyenek a más process általi 
>> módosítástól (pl. mutex).
>>
>> A hagyományos Unix ez úgy oldotta meg, hogy az egész kernel kvázi egy 
>> hatalmas mutex alatt volt, ha egyszer valaki belépett a kernelbe, pl. egy 
>> rendszerhívásba, akkor egészen addig nem léphetett be senki más, amíg o 
>> ki nem lépett. Ez egyrészt rontja a multiprocesszoros muködés 
>> hatékonyságát, mert csak egy folyamat lehet bent a kernbelben (pl. 
>> fájlrendszer muködés), a másiknak a másik processzoron várnia kell, amíg 
>> o ki nem lép.
>>
>> Minál jobban fel tudod bontani a kernelt olyan kis részekre amelyeket 
>> külön kölcsönös kizárással védhetsz, annál jobb lesz a dolog, mert annál 
>> kisebb lesz a valószínusége, hogy két processz ugyanazon a részen akar 
>> futni.
>>
>
>
>
> -----------------------------------
> Szponzorunk: http://tonerbolt.hu/
>