[OSy] Ochrana mallocu

[Andrej Kruták]

Hoj,

no riesenie je jednoduche - mutexy by nemali pri volani lock/unlock
alokovad/dealokovavat ziadnu pamat... Nie je az taky problem spravit si
strukturu vlakna tak, ze tie vlakna mozes potom zapajat do nejakeho zoznamu
(teoreticky... prakticky je to trochu zlozitejsie, ale aj nam sa to podarilo
:-))...

Andrej

On Dec 30, 2007 5:42 PM, Josef Reidinger <josef.reidinger at seznam.cz> wrote:

> Dobry den,
> delame na prvnim rozsirenem zadani. A pri zajistovani primitivy jsme se
> dostali do situace ze ktere si nevim rady co s ni. Problem je
> nasledujici: Malloc je chranen synchronizacnim primitivem. Jeden proces
> si zamkne malloc. Kdyz se pokusi jiny proces taky mallocovat, tak se
> uspi. Ale tady je kamen urazu, protoze tento jiny proces musi byt pridan
> do fronty uspanych procesu a k tomu se opet pouziva malloc, takze se
> program dostane do nekonecne smycky (spis ale deathlock, kvuli
> zamknutemu mutexu).
> rekurzivni synchronizacni primitiva nejsou reseni tohoto problemu,
> protoze kazde dalsi se akorat prida do seznamu cekajicich a tim porad
> vola malloc.
> Ochrana spinlockem, krome toho ze neni efektivni, tak taky vzhledem k
> tomu ze spinlock nezarucuje ferovost pristupu casto skonci uvaznutim
> nektereho z cekajicich procesoru (stava se to vetsi u poctu procesoru
> pres patnact).
> Dalsi reseni mne moc nenapadaji (krome nejakych krkolomnych). Neni
> nejake jednodusi reseni ochrany mallocu?
> JR
>
> _______________________________________________
> OSy mailing list
> OSy at dsrg.mff.cuni.cz
> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20071230/d3e1c500/attachment.html>