dementi -- Re: Pentium - co s nim ? (lehce delsi)

[Pavel Machek]

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/ ;-).