116
-
dez #116 Épp ezért csak magasabb jogokkal használható, asszem. -
BiroAndras #115 Érdekes. Ezek szerint elég időnként meghívnom a setpriority-t, és máris legyőztem a scheduler-t. -
dez #114 "A felhasználó szempontjából a nice megfelel a win-es prioritásnak."
Egyébként ez sem igaz így, de mindegy. -
dez #113 Nem. Unixon/Linuxon is állítható az alap prioritás. Lásd getpriority()/setpriority(). Csak ez bizonyos feltételekkel használható, miközben a nice szabadabban, viszont maga a nice korlátozottabb. -
BiroAndras #112 "Egy prioritás van, amit a nice is befolyásol."
win-en a prioritás állítod. Linuxon te a nice-t állítod (meg a class-t), amiből a scheduler számol egy dinamikus prioritást. A felhasználó szempontjából a nice megfelel a win-es prioritásnak. A többi az eltérő scheduler algoritmusból adódik. -
dez #111 "Igen, de ez a prioritás nem az a prioritás, mint win-en."
-- Egy prioritás van, amit a nice is befolyásol.
"Annak a nice felel meg"
-- Csak távolról felel meg neki.
"amit viszont kizárólag a programozó állít."
-- Láttam én már olyat, ahol a nice-t állították.
"A prioritás itt a kernel által dinamikusan számolt érték, ami segíti az ütemezést."
-- Lásd, amit fent írtam.
"Le van írva pontosan, hogy mi a nice. A kernel által számolt prioritáshoz adódik hozzá, így a júzer tudja befolyásolni a számolt értéket."
-- Aham, jó.
"Ezek az osztályok azt mondják meg, hogy hogyan kezelje a scheduler az adott process-t, nem a prioritás állítás/nem állítás a lényegük."
-- Természetesen. De ehhez hozzátartozik a prioritás-állítás engedélyezése/tiltása is.
"Win-en hasonlóan működnek a prioritások, csak ott a scheduler algoritmus fix."
-- Távolról hasonlít, közelről eléggé más. -
BiroAndras #110 "Itt nincs félreértés. Mint látod, dinamikusan állítja az OS a prioritást."
Igen, de ez a prioritás nem az a prioritás, mint win-en. Annak a nice felel meg, amit viszont kizárólag a programozó állít. A prioritás itt a kernel által dinamikusan számolt érték, ami segíti az ütemezést.
"Azt hiszem, a nice is a tulajdonképpeni prioritást állítja, csak korlátok között"
Le van írva pontosan, hogy mi a nice. A kernel által számolt prioritáshoz adódik hozzá, így a júzer tudja befolyásolni a számolt értéket.
"Ja, és még kérdezted, hogy jelzi a program, hogy átállíthatja-e az OS a prioritását. Nos, két módja is van. 1. különféle classok vannak, úgy mint realtime, time-sharing, fair-share, fixed-priority. Továbbá ezeken belül is beállíthatók bizonyos policy-k erre vonatkozólag (pl. átmenetileg)."
Ezek az osztályok azt mondják meg, hogy hogyan kezelje a scheduler az adott process-t, nem a prioritás állítás/nem állítás a lényegük.
És egyébként, ha akarom így is el tudom venni teljesen a CPU-t a többiektől.
Win-en hasonlóan működnek a prioritások, csak ott a scheduler algoritmus fix.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/scheduling_priorities.asp
Érdemes elolvasni a többi részt is. -
dez #109 Na nézzük:
"Early Unix implementations use a scheduler with Multilevel Feedback Queues with round robin selections within each Feedback Queue. In this system, processes begin in a high priority queue (giving a quick response time to new processes, such as those involved in a single mouse movement or keystroke), and as they spend more time within the system, they are preempted multiple times and placed in lower priority queues. Unfortunately under this system older processes may be starved of CPU time by a continual influx of new processes, although if a system is unable to deal with new processes faster than they arrive, starvation is inevitable anyway. Process priorities could be explicitly set under Unix to one of 40 values, although most modern Unix systems have a higher range of priorities available (Solaris has 160). Instead of the Windows NT 4.0 solution to low priority process starvation (bumping a process to the front of the round robin queue should it be starving), early Unix systems used a more subtle aging system, to slowly increase the priority of a starving process until it was executed, whereupon its priority would be reset to whatever it was before it started starving."
(Hozzátenném: későbbi unix verziókban és implementációkban újabb megoldások születtek, de többnyire mindnek sajátja ez a dinamikus módosítás.)
Itt nincs félreértés. Mint látod, dinamikusan állítja az OS a prioritást.
Most az, hogy prioritásnak vagy nice-nak hívjuk, egy másik kérdés. Azt hiszem, a nice is a tulajdonképpeni prioritást állítja, csak korlátok között (magát a számot tekintve, illetve csak user processeké állítható, stb.). Mindenesetre általában nice-ként szokták emlegetni a unix-os prioritást, mivel user szinten az az.
Ja, és még kérdezted, hogy jelzi a program, hogy átállíthatja-e az OS a prioritását. Nos, két módja is van. 1. különféle classok vannak, úgy mint realtime, time-sharing, fair-share, fixed-priority. Továbbá ezeken belül is beállíthatók bizonyos policy-k erre vonatkozólag (pl. átmenetileg). -
dez #108 Jahh, hogy már itt a végefelé...
Nos azért számít az év, mert idő kell, amíg a felhasználók hiányolni kezdenek valamit. Talán nem is lehet az aktuális implementációt csak úgy megváltoztatni, de egy új eltérhet. Persze ha a gyártó nem figyel oda a részletekre, akkor neki mindegy. -
BiroAndras #107 "És? Két dolog van odaírva: 1. dinamikus prioritás-állítás az OS részéről, 2. pontosítás, miszerint unixon nem a prioritást, hanem a nice-t állítja át (mint később írtam, a prioritás helyett van a nice, ami nem teljesen ugyanaz)."
1. Az OS nem állítja a nice-t.
2. A nice nem a prioritás alparamétere, hanem tulajdonképpen a user által állítható prioritás.
Itt le van írva a win és unix scheduler működés:
http://en.wikipedia.org/wiki/Scheduling_(computing)
http://www.cs.unt.edu/~jacob/classes/5640/notes/chapter5.html
Jól látszik szerintem, hogy mit értettél félre. -
BiroAndras #106 ""Ezt én is írtam"
-- Hol is?"
#95:
Egyébként, ha konkrétan csak a preemptive multitasking-ról beszélünk, akkor igaz, hogy saját tapasztalatuk nem volt.
"Csak mert még ma sem tették meg."
Ismétlem : Miért érdekes, hogy hány évük volt rá, ha nem nehéz feladat?
-
dez #105 Az a "kevés köz" az az API egyes elemeinek visszafelé kompatibilitása. Miközben alapvető eltérések is vannak, és rengeteg új elem.
"Ezt én is írtam"
-- Hol is?
"de te az egész win-ről beszéltél, amire már nem igaz."
-- Inkább úgy lehetne mondani, nem teljesen igaz, vagyis nagyrészt igaz.
"Egyébként meg, ha te is elismered, hogy nem nagy ügy egy scheduler-t paraméterezni, akkor miért érdekes, hogy 13 vagy 30 vagy akárhány évük volt rá?"
-- Csak mert még ma sem tették meg.
"Inkább te szoktad."
-- Dedós dolog így visszadobni a pöttyöslabdát, főleg, hogy a tiéd.
"Én ezt írtam : "A win a mai napig cipeli a 16-bites történelmet."
Te erre azt írtad, hogy : "Már csak egy elkülönített dobozban (soapboxban)."
Erre mondtam, hogy ez így ebben a formában nem igaz. A 16 bites programok persze elkülönítve futnak, de ez csak egy része a kompatibilitásnak, mint ahogy a linkek is mutatják."
-- Oké, ebben valamennyire igazad van. De az a "történelemcipelés" az API kis részét érinti.
"És igaz, hogy a scheduler szempontjából ez nem számít, de te általánosabban beszéltél a 16/32 bites win-ekről, nem pedig csak a cooperative és preemptive működés különbségeiről. Hogy a két váltás egybeesik, az nem szükségszerű (bár nem is véletlen)."
-- Nagyon nem véletlen, mivel összefügg a 32 bites x86-ok bizonyos új képességeivel. A korábbi procikon nehézkes lett volna a pre-emptive multitask. -
dez #104 És? Két dolog van odaírva: 1. dinamikus prioritás-állítás az OS részéről, 2. pontosítás, miszerint unixon nem a prioritást, hanem a nice-t állítja át (mint később írtam, a prioritás helyett van a nice, ami nem teljesen ugyanaz). -
BiroAndras #103 "Senki sem mondta, hogy totál különbőző."
Ezt írtad:
"Nos, a legelső, kezdetleges, 16 bites Windowst 1985-ben mutatták be. De a mai Windowsnak nem sok köze ehhez."
"Amiről itt beszélünk, abban alapvetően más. A pre-emptive multitasking finomítására 13 évük volt, mert azóta létezik pre-emptive multitaskos Windows."
Ezt én is írtam, de te az egész win-ről beszéltél, amire már nem igaz.
Egyébként meg, ha te is elismered, hogy nem nagy ügy egy scheduler-t paraméterezni, akkor miért érdekes, hogy 13 vagy 30 vagy akárhány évük volt rá?
"Már unom, hogy állandóan meghamisítod itt a történelmet."
Inkább te szoktad.
"Azt írtad, "nem egészen", és belinkeltél olyan lapokat, ahol visszafelé kompatibilitási miatti esetek vannak taglalva. Csak éppen ezt teljesen félreértetted, nem azért van ez a visszafelé kompatibilitás itt, hogy a WIN16-os exe-k fussanak WIN32-n."
Én ezt írtam : "A win a mai napig cipeli a 16-bites történelmet."
Te erre azt írtad, hogy : "Már csak egy elkülönített dobozban (soapboxban)."
Erre mondtam, hogy ez így ebben a formában nem igaz. A 16 bites programok persze elkülönítve futnak, de ez csak egy része a kompatibilitásnak, mint ahogy a linkek is mutatják.
És igaz, hogy a scheduler szempontjából ez nem számít, de te általánosabban beszéltél a 16/32 bites win-ekről, nem pedig csak a cooperative és preemptive működés különbségeiről. Hogy a két váltás egybeesik, az nem szükségszerű (bár nem is véletlen).
"Ez egy újabb tévedés. Mégis, hogy képzeled? Csak egyszerűen rosszul volt implementálva a WIN16-os környezet, kevésbé volt szeparált."
Én is úgy értettem, hogy "kevésbé volt szeparált.". Nem találom a cikket, amiben erről olvastam, de a wiki is ír róla egy keveset (http://en.wikipedia.org/wiki/History_of_Microsoft_Windows#Windows_95). -
BiroAndras #102 "De igen, pontosan erről beszéltem."
Ezt írtad :
Inkább talán az az oka, hogy a Windows nem 30 éves... És a MS nem foglalkozik ilyenekkel. Ott nincs a process leíróban olyan, hogy átállíthatja-e a rendszer a prioritást.
(Pontosabban, itt talán inkább a prioritás "al-paraméteréről" van szó, amit Unixon "nice"-nak hívnak. Asszem -5 és +5 között változhat. Ilyen Windowson eleve nincs.) -
dez #101 "Nem ugyanazt írták meg természetesen. De nem is totál különbözőt."
-- Tudnád hanyagolni az ilyen semmitmondó, tök fölösleges kijelentéseket? Senki sem mondta, hogy totál különbőző. Azt mondtam, bizonyos alapvető és sok kisebb dologban más. Amiről itt beszélünk, abban alapvetően más. A pre-emptive multitasking finomítására 13 évük volt, mert azóta létezik pre-emptive multitaskos Windows. Ezt tényleg ilyen hihetetlen nehéz felfogni?
"Ezt nem próbáltam cáfolni, mivel így van."
-- Már unom, hogy állandóan meghamisítod itt a történelmet. Azt írtad, "nem egészen", és belinkeltél olyan lapokat, ahol visszafelé kompatibilitási miatti esetek vannak taglalva. Csak éppen ezt teljesen félreértetted, nem azért van ez a visszafelé kompatibilitás itt, hogy a WIN16-os exe-k fussanak WIN32-n.
"Egyébként csak az NT vonalon, mert a 9x-ekben vegyes 32/16 bites kernel volt (többek közt ennek volt köszönhető a sok stabilitási probléma)."
-- Ez egy újabb tévedés. Mégis, hogy képzeled? Csak egyszerűen rosszul volt implementálva a WIN16-os környezet, kevésbé volt szeparált. -
dez #100 "Értem a különbséget, de eddig nem erről beszéltél."
-- De igen, pontosan erről beszéltem. Ezt írtam a nice-ről: "..a nice azt állítja-e, hogy azonos prioritáson lévő processek hogyan osztozzanak a prociidőn..". Meg azt is írtam, hogy unix-on nem win-féle prioritás van, hanem.. a nice. Azt egy szóval sem mondtam, hogy ez a nice állítaná saját magát.
"Az meg nem is derül ki a szövegből, hogy pontosan ki mennyi procit kap."
-- Most tized %-ra, vagy mi? :D Lényeg, hogy arányosan többet-kevesebbet a nice értéktől függően.
"Valamennyi procit win-en is kap minden process, kivéve az idle prioritásúak."
-- Aha, pár másodpercenként 0.1s-t.
"Egyébként ez csak egy beállítás a scheduler-ben, nem egy olyan nagy bonyolult technolóia. Nyílván megvan az oka, hogy miért úgy működik a win ahogy."
-- Senki sem mondta, hogy olyan hű de bonyolult. De mindent el lehet ugye hanyagolni.
"Amiről beszéltél, hogy az OS állítja a process prioritását."
-- Nézd meg jobban a unix-os schedulereket. Több kicsit eltérő implementáció is van. -
BiroAndras #99 "Jaj, de nehéz megértened, hogy hiába próbálták volna ugyanazt megírni, csak már 32 bitesen, amikor alapvető különbségek vannak."
Nem ugyanazt írták meg természetesen. De nem is totál különbözőt.
"Különben is te itt azt a tényt próbáltad cáfolni, hogy a WIN16-os programok egy soapboxban futnak, ami biztosítja nekik a WIN16-os körülményeket."
Ezt nem próbáltam cáfolni, mivel így van. Egyébként csak az NT vonalon, mert a 9x-ekben vegyes 32/16 bites kernel volt (többek közt ennek volt köszönhető a sok stabilitási probléma). -
BiroAndras #98 "Úgy látom te nem tudsz."
-- De tudok, sőt veled ellentétben értelmezni is. ;)
"A nice ilyenkor az arányokat állítja, ezzel ellentétben winen egy magasabb prioritású process az idő 99.9%-át megkapja, és a maradék 0.1%-ot is a rendszer kapja meg, nem az alacsonyabb prioritású processek. Nem érted a különbséget?"
Értem a különbséget, de eddig nem erről beszéltél. Az meg nem is derül ki a szövegből, hogy pontosan ki mennyi procit kap. Valamennyi procit win-en is kap minden process, kivéve az idle prioritásúak.
Egyébként ez csak egy beállítás a scheduler-ben, nem egy olyan nagy bonyolult technolóia. Nyílván megvan az oka, hogy miért úgy működik a win ahogy.
"Itt milyen befolyásolásra gondolsz?"
Amiről beszéltél, hogy az OS állítja a process prioritását. -
dez #97 Jaj, de nehéz megértened, hogy hiába próbálták volna ugyanazt megírni, csak már 32 bitesen, amikor alapvető különbségek vannak.
Különben is te itt azt a tényt próbáltad cáfolni, hogy a WIN16-os programok egy soapboxban futnak, ami biztosítja nekik a WIN16-os körülményeket.
A tapasztalati különbséget nem úgy értettem, ahogy te, de mindegy. -
dez #96 "Hasonló a célja és a hatása is, így nem teljesen más. Mondtam is, hogy csak hasonló, nem ugyanaz."
-- Ilyen alapon igen távoli dolgok is hasonlóak valahol, valamiben.
"Úgy látom te nem tudsz."
-- De tudok, sőt veled ellentétben értelmezni is. ;)
"Lefordítom magyarra: Ha a CPU nem képes kiszolgálni az összes process-t, akkor a magasabb prioritású kap több CPU időt. Ez lényegében a prioritás definíciója."
-- Tévedés. A nice ilyenkor az arányokat állítja, ezzel ellentétben winen egy magasabb prioritású process az idő 99.9%-át megkapja, és a maradék 0.1%-ot is a rendszer kapja meg, nem az alacsonyabb prioritású processek. Nem érted a különbséget?
"Nincs szó arról, hogy a szoftver íróján kívül bárki hozzápiszkálna a prioritásokhoz."
-- Naná, hogy itt nincs róla szó, mert az egy másik téma, még ha van is köze ehhez.
"Hanem? Nem találtam hivatkozást más paraméterre, amivel a scheduler-t lehetne befolyásolni."
-- Itt milyen befolyásolásra gondolsz? -
BiroAndras #95 Megpróbálom egyszerűbben elmagyarázni:
Szerinted az alábbi két változat közül melyik a valószínűbb?
a) A win32 fejlesztését úgy kezdték, hogy kitörölték az egész win16 kódot, kirúgták az összes programozót, és nulláról újrakezdték.
b) Ugyanazok a programozók írtak egy új 32 bites kernelt, felhasználva a korábbi tapasztalatokat, majd módosították a kód többi részét ahol kellett.
Egyébként, ha konkrétan csak a preemptive multitasking-ról beszélünk, akkor igaz, hogy saját tapasztalatuk nem volt. Viszont ehhez meg volt több évtizednyi tapasztalat más OS-ekkel (pl. unix). És ezek a tapasztalatok nem hétpecsétes titokként voltak őrizve, hanem többnyire részletesen publikálták, és tanították az egyetemeken őket. Meg simán unix programozás közben is lehetett tapasztalatot szerezni. -
BiroAndras #94 "Ez teljesen más, mint amiről én beszéltem."
Hasonló a célja és a hatása is, így nem teljesen más. Mondtam is, hogy csak hasonló, nem ugyanaz.
"Nem igaz. Tudsz olvasni?"
Úgy látom te nem tudsz.
Nice becomes useful when several processes are demanding more resources than the CPU can provide. In this state, a higher priority process will get a larger chunk of the CPU time than a lower priority process.
Lefordítom magyarra: Ha a CPU nem képes kiszolgálni az összes process-t, akkor a magasabb prioritású kap több CPU időt. Ez lényegében a prioritás definíciója. Nincs szó arról, hogy a szoftver íróján kívül bárki hozzápiszkálna a prioritásokhoz.
"És én nem is csak a nice-ről beszéltem."
Hanem? Nem találtam hivatkozást más paraméterre, amivel a scheduler-t lehetne befolyásolni. -
dez #93 "korábban megírt függvényt átírni" -> mármint nem rendszerfüggvényt, hanem applikációs programok függvényeit. -
dez #92 Félreérted. A WIN16-os programok a WIN16-os alrendszeren futnak, nem a WIN32-esen. Itt arról van szó, hogy az új API (WIN32) egy része próbál kompatibilis lenni a régivel (WIN16), hogy ne kelljen minden egyes korábban megírt függvényt átírni. -
dez #91 "Egyébként van is a win-ben hasonló mechanizmus, bár egyszerűbb. Minden process időnkén egy nagyon rövid időre magasabb prioritást kap, így biztosan hozzájut a CPU-hoz."
-- Ez teljesen más, mint amiről én beszéltem.
"Egyébként, egyáltalán nem úgy működik a dolog, ahogy leírtad. A nice egyszerűen a prioritást jelenti a unix-okon."
-- Nem igaz. Tudsz olvasni?
Nice becomes useful when several processes are demanding more resources than the CPU can provide. In this state, a higher priority process will get a larger chunk of the CPU time than a lower priority process.
És én nem is csak a nice-ről beszéltem. -
dez #90 "Igen, de ez nem jelenti azt, hogy a 32 bites win egy alapvetően más OS lenne."
-- Több alapvető, és sok kisebb különbség van.
"Itt a tapasztalatról van szó leginkább. Az, hogy 16 vagy 32 bites az OS, elsősorban a kernelt érinti, ami bármenyire is fontos, csak kis része az OS-nek."
-- És a kooperatív vs. pre-emptive multitask nem jelent tapasztalati különbséget? Nagyon is. És mivel az API-k is eléggé mások, egy applikáció-programozó számára is jól tapasztalható a különbség... -
BiroAndras #89 "Már csak egy elkülönített dobozban (soapboxban)."
Nem egészen. Csak pár példa:
http://blogs.msdn.com/oldnewthing/archive/2004/03/19/92648.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/03/02/82639.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/11/08/253891.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/06/15/156022.aspx
http://blogs.msdn.com/oldnewthing/archive/2006/01/30/519388.aspx
-
BiroAndras #88 "Ez azt akarja jelenteni, hogy megoldott ez a dolog, hogy egy process jelezheti, hogy az OS magától átállíthatja a prioritását, ha nagyon terjeli a procit, és az OS ezt meg is teszi?"
Nem. Ezt kérdezted, foglalkozik-e az MS ilyesmivel. Nem konkrétan ezzel, hanem ilyesmivel.
Egyébként van is a win-ben hasonló mechanizmus, bár egyszerűbb. Minden process időnkén egy nagyon rövid időre magasabb prioritást kap, így biztosan hozzájut a CPU-hoz.
Egyébként, egyáltalán nem úgy működik a dolog, ahogy leírtad. A nice egyszerűen a prioritást jelenti a unix-okon.
http://en.wikipedia.org/wiki/Nice_%28Unix%29 -
BiroAndras #87 "Aztért azt tegyük hozzá, hogy a WIN16-os programok egy az OS többi részétől elkülönített, virtuális környezetben futnak, kooperatív módban, aminek nem sok köze van a rendszer többi részéhez."
Igen, de ez nem jelenti azt, hogy a 32 bites win egy alapvetően más OS lenne.
"Átvehettek kódrészeket, de alapvetően más környezet, és itt most erről van szó."
Itt a tapasztalatról van szó leginkább. Az, hogy 16 vagy 32 bites az OS, elsősorban a kernelt érinti, ami bármenyire is fontos, csak kis része az OS-nek. -
dez #86 "A win a mai napig cipeli a 16-bites történelmet."
Már csak egy elkülönített dobozban (soapboxban). -
dez #85 Nem a Taskmanager (az nyilván), hanem az a registryben állítható dolog. -
dez #84 "Igen. Neked is tudom ajánlani ezt a blogot : http://blogs.msdn.com/oldnewthing/"
-- Ez azt akarja jelenteni, hogy megoldott ez a dolog, hogy egy process jelezheti, hogy az OS magától átállíthatja a prioritását, ha nagyon terjeli a procit, és az OS ezt meg is teszi?
Ha így van, mégis miért kell állandóan kézzel csinálni?
"Te nem érted. Az alkalmazás mondja meg, hogy az ütemező hogy bánjon vele."
-- Hogyan?
"Lehet, hogy unix-on jobban be lehet állítani, de ez keveset ér, ha a programozó bénázik."
-- Gondolom az alapeset az, hogy átállíthatja. Ha fontos, hogy ne állíthassa át, csak nem felejti el a programozó. -
dez #83 "De van köze. A 16 bites API ma is működik. Elvileg a win 1.0-ra írt programok mennek Vistán is. Ez tette a win-t siekressé, de pont emiatt van annyi baj is vele."
-- Aztért azt tegyük hozzá, hogy a WIN16-os programok egy az OS többi részétől elkülönített, virtuális környezetben futnak, kooperatív módban, aminek nem sok köze van a rendszer többi részéhez.
"Nem nulláról kezdték a fejlesztést. Az NT is a korábbi win-ekre épült, csak már egy sokkal fejlettebb proci volt alatta, amit ki is használt."
-- Átvehettek kódrészeket, de alapvetően más környezet, és itt most erről van szó. -
BiroAndras #82 "~'85-ben? Az M68000-es, belülről. (Kívülről meg multiplexelt volt az adatbusz, így - bár két hozzáféréssel - szépen ki tudta írni/be tudta olvasni a 32 bites adatot! De ezzel nem kellett foglalkoznia a programozónak.) Így a MacOS, AmigaOS, stb. eleve 32 bitesek voltak. Utóbbi pre-emptive is volt már akkor."
Hát, sokkal fejlettebb procira könnyű jobb OS-t írni. A win a mai napig cipeli a 16-bites történelmet. -
BiroAndras #81 "Amúgy is csak kicsit segít."
A Task Manager? Próbáltad már? Rettenetesen sokat tud segíteni. Csak az a bánata, hogy ha egy nagyon magas prioritású szál ragad be, akkor neki sem jut proci. Szerencsére több magnál ez már sokkal ritkábban fordulhat elő (1 beragadt szál nem fogja le az összes magot). -
BiroAndras #80 "Foglalkozik...?"
Igen. Neked is tudom ajánlani ezt a blogot : http://blogs.msdn.com/oldnewthing/
"Nem értetted a lényeget. Próbáld újra!"
Te nem érted. Az alkalmazás mondja meg, hogy az ütemező hogy bánjon vele. Lehet, hogy unix-on jobban be lehet állítani, de ez keveset ér, ha a programozó bénázik. -
BiroAndras #79 "Ebbe a DOS-t is beleszámoltad?"
Nem.
"Nos, a legelső, kezdetleges, 16 bites Windowst 1985-ben mutatták be."
The history of Windows dates back to September 1981, when the project named "Interface Manager" was started. It was first presented to the public in November 10, 1983, renamed to "Microsoft Windows"
http://en.wikipedia.org/wiki/Windows_1.0
"De a mai Windowsnak nem sok köze ehhez."
De van köze. A 16 bites API ma is működik. Elvileg a win 1.0-ra írt programok mennek Vistán is. Ez tette a win-t siekressé, de pont emiatt van annyi baj is vele.
"Az első 32 bites, normálisabb Windowst (NT) csak 1993-ban! Ez csak 13 év..."
Nem nulláról kezdték a fejlesztést. Az NT is a korábbi win-ekre épült, csak már egy sokkal fejlettebb proci volt alatta, amit ki is használt. -
![[Jakuza]](https://media.sg.hu/forum/avatars/10427091571053517846.jpg "[Jakuza]")
#78
Jo van csak erolkodj tovabb. -
dez #77 Megint nem figyeltél eléggé, csak kötekedsz csípőből.
Egy olyan fícsörről volt szó, aminek csak pre-emptive rendszerben van értelme. Pre-emptive Windows meg csak 1993-tól van. Kapís? :)