rwlock [Was: Re: Uzivatelska pritulnost Linuxu (dlouhe)]

[Pavel Kankovsky]

On 10 May 2000, Stanislav Meduna wrote:

> To ma samozrejme napadlo tiez, ale to proste rozumne nejde
> (a konkretne v danej aplikacii by bol overhead pravdepodobne
> daleko vyssi nez to, co by som tym ziskal).

Pri vsi ucte: v takovem pripade je ta paralelizace asi zbytecna obecne,
protoze smysluplne paralelizovany system maximalizuje mnozstvi prace "na
svem pisecku" vzhledem k mnozstvi interakce mezi jednotlivymi procesy.

> Je tu ale vaznejsi problem: pthreads mi garantuje, ze sa
> writer dostane k lizu (pokial spravne interpretujem
> nasledujuci trochu zmateny text - rozdiel medzi blocked
> a waiting mi trochu unika):

Mne ten rozdil taky unika, ale to je jedno.

> Toto IMHO pri "dvojstupnovej" implementacii zaistit nejde.

Zamky na souborech vskutku z definice nezarucuji, ze nekdo nebude hladovet
(i kdyz je to asi v praxi nepravdepodobne a koneckoncu by se asi dalo
najit vic patologickych scenaru, pri kterych bude v jadre neco hladovet
(aspon pokud je hladoveni mozne pri zamykani souboru), takze by nemelo
valny smysl resit tento jeden partikularni problem).

Na druhou stranu jsem si ale nevsimnul, ze by ve Win32 neco takoveho neco
zarucovalo, nemluve o tom, ze mi neni jasne, ktery z 57 vicemene
redundantnich synchronizacnich mechanismu ve Win32 by mel byt pouzit,
protoze nic primo jako rwlock tam neni a u semaforu jsem si nevsimnul, ze
by zamceni umoznovalo snizit hodnotu semaforu atomicky o vic nez o jedna.
;)

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."