Mariusz Kruk pisze:
> W kwestii formalnej - nie do koñca. System wykorzystuje procesory np.
> przy operacjach dyskowych, czy sieciowych. I mo¿e lepiej lub gorzej
> wykorzystywaæ wieloprocesorowo¶æ robi±c to.
Zacytujê samego siebie:
"[...] choæ oczywi¶cie ka¿dy kolejny system jest lepiej zopty-
malizowany pod k±tem systemów wieloprocesorowych oraz uk³adów
wielordzeniowych [...]".
A wiêc napisa³em o tym. Inna sprawa, ¿e to, o czym mówisz,
liczy siê tylko w BARDZO konkretnych zastosowaniach, na
przyk³ad w serwerze plików z wieloma macierzami programo-
wymi czy w routerze wyposa¿onym w kilka gigabitowych inter-
fejsów. W typowych zastosowaniach wp³yw przystosowania sys-
temu wej¶cia/wyj¶cia i innych funkcji systemowych do pracy
wieloprocesorowej jest pomijalnie ma³y.
Udowodnili to zreszt± autorzy Mac OS X, dopiero *niedawno*
rezygnuj±c z modelu Big Kernel Lock na rzecz niezale¿nych
muteksów (*) steruj±cych wej¶ciami do poszczególnych bloków
funkcjonalnych systemu. Przy dwóch rdzeniach i typowych
zastosowaniach biurkowych (czyli aplikacje GUI, licz±ce
co¶ sobie wewnêtrznie) po prostu siê *nie op³aca³o* robiæ
tego wcze¶niej. Dopiero o¶miordzeniowe Maki zaczê³y wyra¼-
nie zwalniaæ z powodu prymitywno¶ci budowy j±dra.
Swoj± drog± Windows NT zawsze mia³o bardzo indywidualne
muteksy (od samego pocz±tku, na wyrost w zasadzie pocz±t-
kowo), a w Windows 2000, XP i Vi¶cie dalej poprawiano to,
by umo¿liwiæ maksymalnie równoleg³± pracê czego tylko siê
da. Co najwy¿ej sterowniki urz±dzeñ mog± marnie siê spra-
wowaæ przy pracy równoleg³ej, ale tu autor systemu nie-
wiele ju¿ mo¿e zrobiæ (poza zapewnieniem przyzwoitej infra-
struktury sterowników).
------------------------------------------------------------
(*) Pojêcia "muteks" u¿ywam tu w pojêciu ogólnym, w oderwa-
niu od faktycznej realizacji sposobu blokady jednoczes-
nego wej¶cia wielu w±tków.
-- |""""""""""""""""""""""""""""""""""""""""""""""""""""""""""| | Rados³aw Sokó³ | http://www.grush.one.pl/ | | | Administrator, Politechnika ¦l±ska | \................... Microsoft MVP ......................../Received on Mon Jun 2 15:00:28 2008
To archiwum zosta³o wygenerowane przez hypermail 2.1.8 : Mon 02 Jun 2008 - 15:51:01 MET DST