dementi -- Re: Pentium - co s nim ? (lehce delsi)
Pavel Machek
pavel na Elf.mj.gts.cz
Pondělí Listopad 10 22:09:23 CET 1997
Ahoj!
> > Jsi si jisty tim ze LOCK se nema podarit userovemu procesu? Nemam po
> > ruce specifikace, ale podle me ma bezny proces na lock pravo.
> [...]
>
> Podival jsem se do "Chytre Knihy" a zjistil jsem, ze jsem kazal bludy
> (jako obvykle)--ona je cela vec totiz dost slozita:
[snip]
> 286: LOCK je privilegovana instrukce (musi byt CPL <= IOPL)
> ale stale asi smi byt pouzita s jakoukoli instrukci
(Hmm, tak o tomhle jsem nemel ani tuseni ;-).
> 386: LOCK je privilegovana instrukce POUZE v VM86, v "native" modu
> se smi pouzivat libovolne (pokud je splnena nasledujici podminka)
> LOCK smi byt pouzit pouze s omezenou mnozinou instrukci, ktere
> navic musi mit operand, ktery jest v pameti
>
> 486: jako 386, ale do mnoziny povolenych instrukci pribyva CMPXCHG
> (nebo jak se ta hruznost jmenuje, ale je to presne ta, na ktere
> to tuhne--na Pentiu)
Budes opraven jeste jednou. Pentium tuhne na cemsi co *neni* platna
instrukce. Kdyby to byla platna instrukce, bylo by to cosi jako
CMPXCHG; jenze ona neni.
> Pentium..: ??? ("Chytra Kniha" uz neni nejmladsi, tak o tom nic
>nerika)
Doufam ze kompatibilni s 386.
Jeste abych zareagoval na followup nekoho jinyho: Uzivatelske aplikace
samozrejme maji pravo sdilet si pamet a komunikovat v ni jak uznaj za
vhodne. _NE_ni to navrat k MSDOGu, protoze obe aplikace musi
souhlasit. Pouziva se to napr. v okoli Xserveru, protoze je to
spolehlive nejjednodussi metoda jak komunikovat.
Pavel
--
I'm really pavel na atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).
Další informace o konferenci Linux