Re: wywlaszczanie w intelach, : 16 bitowosc win95

Autor: Radosław Sokół (rsokol_at_iname.com)
Data: Tue 14 Apr 1998 - 13:06:31 MET DST


Grzegorz Szysz/lo wrote:

Widzę, że przerobiłeś subject z "Windows 95" na "Intel",
żeby podpaść pod tematykę grupy? ;)

> bzdura. wywlaszczane moga byc zarowno fragmenty 16bitowe, jak
> i 32bitowe.

Tak, ale pytanie dotyczyło Windows 95, a tam scheduler nie
pozwala na wywłaszczanie kodu 16-bitowego (dokładniej:
nie są tworzone instancje zmiennych bibliotek DLL dla
każdego wątku więc wywłaszczenie powodowałoby zafałszowanie
wartości tych zmiennych dla poprzedniego wątku. W przypadku
32-bitowych DLL każdy wątek ma własny segment danych DLLa
i nie ma problemu).

> 32bity ulatwiaja jedynie operacje na duuuzych blokach
> danych, z wywlaszczaniem nie maja nic wspolnego. kilka roznych
> systemow ma wywlaszczanie zarowno w 32bitowym, jak i 16bitowym kodzie.
> win95/98 nie ma wywlaszczania ani w jednym, ani w drugim.

W 32 bitach jakieś tam ma, tylko że tych czystych 32-bitowych
DLLi w tym systemie nie ma. Gdyby USER32 i GDI32 nie korzystały
z 16-bitowych DLLi (które nie mogą być wywłaszczane), to
wielozadaniowość Win95 przedstawiałaby się dużo lepiej.

> wywlaszczanie w tych atrapach systemow (wlasciwie to w shellach graficznych)
> odbywa sie w ten sposob, ze
> 1.moze nastapic podczas odwolania do jakiejkolwiek funkcji systemowej

Może wystąpić w przypadku odwołania do 32-bitowego modułu
tworzącego osobne instancje zmiennych dla każdego wątku.

> 2.w przypadku dlugotrwalych petli ktore cos obliczaja, nalezy
> robic wywlaszczanie wymuszone, odwolujac sie do stosownej funkcji
> systemowej.

Yield - to już było w Win16 do obsługi komunikatów i z
wywłaszczeniem ma bardzo mało wspólnego. Zresztą w OS/2 dalej
jest konieczne wywoływanie takich funkcji przy opóźnionym
przetwarzaniu komunikatów, bo inaczej GUI się zatyka (dopiero
Merlin ma jakieś dodatkowe wątki odtykające kolejkę, ale jest
to dość dziwne leczenie błędu architektury).

> takie wywlaszczczanie zostalo juz dawno zrealizowae w DOS'ie ,
> w ........... turbo vision :)

Dokładnie. Zresztą zrobić takie coś nawet samemu to nie
problem.

> >to w momencie ich wywołania ustawiony zostaje
> >tzw. Mutex,
> mutex sluzy do godzenia procesorow w systemach wieloprocesorowych.

Ale Win16Mutex służy właśnie do blokowania wejścia kilku
wątków do tego samego modułu 16bit w Windows 95.

> >Jeśli więc nastąpi zawieszenie się systemu w procedurze
> >systemowej lub jakiś program zapętli się w wywoływaniu
> >tej procedury, to cały interfejs użytkownika i grafika
> >Windowsów padają.
>
> wiec gdzie to "wywlaszczanie" ? to co napisales swiadczy,
> ze wywlaszczanie w windowsach to jedynie reklamowa atrapa.

Bo jest. Wywłaszczenie kodu programu w momencie, gdy ten
rysuje coś na ekranie lub przesuwa okienka jest niemożliwe,
bo wtedy DLLe pozmieniałyby swoje zmienne i po powrocie
do operacji wszystko byłoby nakopane. Programy Win32 mogą
być swobodnie wywłaszczane jedynie gdy wykonują czysty,
obliczeniowy kod nie odwołujący się do bibliotek USER
i GDI.

> >Jedynie KERNEL32 (zarządzanie pamięcią)
> >jest w pełni 32-bitowy i nie korzysta ze starych bibliotek.
>
> z tym sie zgodze. z tym ze on nadal nie jest wielowatkowy.

Na pewno nie jest wielowątkowy, ale może zostać bez
problemów jednocześnie używany zamiennie przez kilka
wątków i przerwanie jego procedury w połowie nie ma
żadnych przykrych konsekwencji.

> >W skrócie: jeden program może z własnej lub systemu winy
> >powiesić całą grafikę.
>
> bzdura. taka sytuacja ma miejsce wylacznie w atrapach systemow
> operacyjnych. przy prawidlowo zrealizowanej wielowatkowosci,

Tak, bo ja w końcu ciągle piszę o Windows 95! :)

> to jest niemozliwe, czego przykladem moze byc praca takich
> systemow jak: SCO Unix, windowsNT (nie cierpie go), Linux czy OS/2 .
                                      ^^^^^^^^^^^^^^
Oj, czemu? :) Taki fajny system... :))))

> wystarczy napisac glupia petle w stylu (przyklad paszczalowy)
> b:=3;
> for x:=1 to 32768 do for y:=1 to 32768 do for z:=1 to 32768 do a:=b*b;
> petle nic nie robia, ale zajmuja procesorowi mnooostwo czasu,
> nie odwolujac sie do funkcji systemowych. windowsy95/98 padaja
> na zbity pysk. do momentu zakonczenia petli, wszystko jest zawieszone.
> pozostale systemy ktore wymienilem, sobie radza i realizuja pozostale
> zadania, lacznie z grafika. kod mozna skompilowac w trybie 16bitowym,
> lub 32bitowym (pod linux tylko 32bitowo). rezultat bedzie zawsze
> ten sam, tylko win95/98 zatrzymuje wszelka inna dzialalnosc.

W momencie, kiedy ten przykład będzie 16bit, na pewno
Win9x go nie wywłaszczy. Jeśli będzie 32bit (BTW czy w ogóle
wartość b zmieści się w zakresie jakiejś zmiennej?), to
Win9x _powinien_ go wywłaszczyć (zgodnie z projektem i
architekturą systemu - scheduler teoretycznie ma możliwość
przerywania modułów EXE 32bit PE). Jeśli naprawdę tego nie
robi, to już nie moja wina, że Microsoft nawet własnych
założeń się nie trzyma.

> reasumujac. 32bitowosc z wywlaszczaniem nie ma nic wspolnego.

Niestety, w Windows 9x ma.

> >Nie wpłynie to na wątki nie wyświetlające
> owszem, ma.

Nie mam Win 9x, więc nie mogę potwierdzić eksperymentalnie,
ale większość testów przeprowadzonych przez laboratoria
gazet (np. PC Magazine) dowodziła, że wątki nie korzystające
z grafiki nie padają przy zawieszeniu w funkcjach 16bit.
Dla mnie nie ma to większego znaczenia, i tak do Windows 9x
się nie zbliżałem od kilku miesięcy i nie mam takiego
zamiaru.

> | Grzegorz Szyszlo mailto:znik_at_wbc.lublin.pl | zmienia postac

PS. Jak tam Twój kot? :)

Pozdrowienia,
|""""""""""""""""""""""""""""""""""""""""""""""""""""|
| Radosław Sokół | mailto:rsokol_at_iname.com |
| | http://friko.onet.pl/ka/lizard/ |
| | What do you want to fix today? |
\. WinNT FAQ: http://friko.onet.pl/ka/lizard/ntfaq/ ./



To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 17:09:58 MET DST