Mitől fagynak le a programok?
2014-12-27T00:24:15+01:00
2014-12-29T00:17:40+01:00
2022-07-22T13:42:04+02:00
  • Szia:)

    gombnyomásra fel lehessen függeszteni a futást, majd később bármikor folytatni


    Ilyen a régi BASIC programozási nyelvben meg is lett valósítva, a gomb pedig PAUSE :D

    felfüggeszteni majd kimenteni HDD-re hogy legközelebb arról a pontról lehessen folytatni.


    Amúgy a mostani Windowsban is be lehet állítani a főkapcsolóra, hogy hibernáljon így viszont az összes folyamat megáll :/ nyilván lehetne alkalmazni hasonló elven egy-egy alkalmazásra is:)

    Írtátok ezt a 100%-os teljesítmény kérdést, ehhez csak annyit írnék, hogy nekem már fagyott le a gép videó konvertálástól, ahol nem volt se végtelen ciklus, se holt pont...
    Mutasd a teljes hozzászólást!
  • Bármilyen feladatot is kell elvégezned, nem nagy dolog mondjuk másodpercenként jelezni az oprendszernek, hogy minden rendben, még dolgozol, illetve ha kell neki a vezérlés, vagy az erőforrás akkor vegye el.

    OK, tegyük fel, hogy létezne egy ilyen jelzés, és a programozók a hosszan futtatni szánt ciklusaikba beépítenék a jelzés periodikus küldését. Mi lenne, ha egy ilyen ciklus valamilyen bug miatt végtelenné válna? Ugyanott lennénk, mint most: nem lehetne tudni, hogy egy hosszan futó ciklus, benne egy periodikus "minden rendben" jelzéssel, tényleg rendben van-e, vagy igazából kifagyott.

    Egyébként valami ilyesmi most is van a Windowsban: a GUI alkalmazások ablakai mindenféle rendszerüzeneteket kapnak a normál futás során. Ha ezeket egy bizonyos időn belül nem dolgozzák fel, akkor jön az általam említett "nem válaszol" felirat a címsorban, illetve a kilövési opció. De persze egy programnak nem csak GUI-val foglalkozó része van, és a többi szál attól még lehet végtelen(nek tűnő) ciklusban, hogy a GUI szál válaszképes.

    Illetve ha a program sok erőforrást lefoglal, akkor elég problémás még a feladatkezelőt is elindítani, vagy bármit csinálni.

    Ebben egyetértek. Néha igazán jól jönne egy olyan billentyűkombináció, ami magas prioritással indítja a Feladatkezelőt, hogy a beragadt normál prioritású processzek ne akadályozzák a futását. Bár most pont kipróbáltam, és Windows 7 alatt a Feladatkezelő nálam alapból magas prioritáson indul, úgyhogy lehet ez már megoldott probléma...

    100% géphasználatot meg eleve nem engedhetünk egy programnak sem, mert a háttérben még sok folyamatnak futnia kell, csak az ezek után szabadon maradó processzor időt kapatja meg a program.

    Azok a háttérfolyamatok az idő 99%-ában inaktívak (nem kérnek CPU-t, mert valami külső eseményre várnak), így aztán a gyakorlatban 100% CPU rendelkezésére szokott állni egy programnak, legalább is ha egyszerre csak egy CPU-igényes programot futtatsz. (Nyilván eltekintve attól a pici időtől, amíg az ütemező elveszi a vezérlést a programtól, rájön hogy nincs más aktív processz, és visszaadja a vezérlést.)
    Mutasd a teljes hozzászólást!
  • Bármilyen feladatot is kell elvégezned, nem nagy dolog mondjuk másodpercenként jelezni az oprendszernek, hogy minden rendben, még dolgozol, illetve ha kell neki a vezérlés, vagy az erőforrás akkor vegye el. Meg eleve most is másodpercenként több tucatszor meg van szakítva a program futása, már 8 bites gépeken is meg volt szakítva, mégsem volt belőle gond.

    Az operációs rendszer be tudja zárni a lefagyott programot, de először udvariasan a programnak küld üzenetet, hogy záródjon már be legyen szíves, és ha hosszabb ideig nem teljesíti akkor zárja be maga. Illetve ha a program sok erőforrást lefoglal, akkor elég problémás még a feladatkezelőt is elindítani, vagy bármit csinálni. Ilyen esetben meg simán adhatna neki kevesebb erőforrást, processzor időt, hogy a rendszer azért használható maradjon. 100% géphasználatot meg eleve nem engedhetünk egy programnak sem, mert a háttérben még sok folyamatnak futnia kell, csak az ezek után szabadon maradó processzor időt kapatja meg a program.
    Mutasd a teljes hozzászólást!
  • Az ember azt gondolná, hogy ma már nem is engedik, hogy valami 100% használja a procit, erőforrásokat hosszabb időn át

    Tehát ne engedjünk játékokat futni a gépen, illetve ne legyen szabad CPU-intenzív számításokat futtatni? Vagy ezeknek csak 90%-os CPU-kihasználást engedélyezzünk, és vesztegessük el a számítási teljesítmény 10%-át?

    hanem kötelező jelleggel vissza kell adni a vezérlést a Windows-nak, illetve vissza veszi az erővel

    A Windows 95 óta "visszaveszi erővel" a CPU-t az oprendszer, ha letelt a kiosztott időszelet. (Lásd: preemptív multitaszk.) Az más kérdés, hogy ha semmi más futtatható feladat nincs, akkor a következő időszeletet is ugyanaz a szál fogja megkapni. Ha nem "venné vissza" az oprendszer periodikusan a vezérlést, akkor nem tudnál mondjuk indítani egy Feladatkezelőt és kilőni a kifagyott programot.

    és ha ilyen beragadt programot észlel akkor intézkedik, mondjuk kevesebb erőforrást ad neki, gond nélkül bezárja ha úgy kérem stb.

    A gond az, hogy elméletben lehetetlen programmal megmondani egy tetszőleges másik programról, hogy éppen végtelen ciklusban van, vagy csak egy nagyon sokáig futó ciklusban (lásd még: megállási probléma). Még azokban az esetekben is, amikor elméletileg lehetséges lenne a végtelen ciklus detektálása, akkor se praktikus egy gépi kódot menet közben analizálni. Innentől kezdve a Windows meg nehogy már bezárja a programomat, csak mert éppen mondjuk videót tömörítek, és ez teljes mértékben lefoglalja az erőforrásokat... (És ugyanígy azt se szeretném, hogy a Windows önkényesen lekorlátozza a programnak kiosztott CPU-időt, és később végezzen a tömörítéssel.)

    Egyébként nagyon ritka esettől eltekintve a programokat igenis be tudod zárni akkor is, ha kifagytak. Ha egy bizonyos ideig nem válaszol az ablak az üzenetekre, kirakja a címsorába a (Nem válaszol) feliratot, aztán ha a bezárás gombra kattintasz, megkérdezi, hogy kilőheti-e. Ha ez nem megy, a Feladatkezelőből akkor is kilőheted a processzt. Nem hiszem, hogy veled még ez sose fordult volna elő. Az más kérdés, hogy egy program kilövése nem feltétlen "gond nélkül" történik, mivel a program által éppen nyitva tartott fájlok, memória illetve egyéb erőforrások nem feltétlen vannak konzisztens állapotban a kilövés pillanatában. Az oprendszer a saját stabilitását meg tudja védeni (bezárja a fájlokat, valamit kezd az egyéb erőforrásokkal), de az adataid attól odaveszhettek.

    Vicces hogy pl a Firefox is 100% átadja a vezérlést egy oldalon lévő JavaScript kódnak, és ha az lefagy akkor a böngésző vissza sem kapja már, lefagy az egész.

    Hmm, szóval te még egyszer se láttad azt a felugró ablakot, hogy "az oldalon futó parancsfájl nem válaszol", ahol felajánlja a szkript kilövését a böngésző? Teljesen ugyanaz az elv, mint a nem válaszoló programok - ha bizonyos ideig nem lát életjelet a böngésző a szkripttől, akkor felajánlja a kilövést. Ugyanúgy, ahogy az oprendszer nem mondhatja biztosra, hogy nem fog magához térni később a program, a böngésző se tudja ezt biztosan, ezért csak felajánlja a kilövést és nem automatikusan végrehajtja. Ha viszont a program valami legitim számításra használja a CPU-t, nincs értelme feleslegesen kevesebbet adni neki és ezzel lelassítani.

     és gombnyomásra fel lehessen függeszteni a futást, majd később bármikor folytatni, esetleg felfüggeszteni majd kimenteni HDD-re hogy legközelebb arról a pontról lehessen folytatni.

    Ilyet nem lehet csinálni a program tudta és beleegyezése nélkül. Ha a program valami kritikus művelet közepén van éppen, te pedig felfüggeszted, akkor az adott erőforrás inkonzisztens állapotban marad, amíg a program nem folytatódik. Mondjuk tipikus holtpont lehetőség lenne, hogy valami más program ugyanazt az erőforrást szeretné használni, de nem fér hozzá, mert az éppen felfüggesztett program zárolja. Tehát felfüggeszteni csak akkor lehetne egy programot, ha előtte egy "biztonságos" állapotba hozod, azt pedig csak a program maga tudná megállapítani, hogy biztonságos állapotban van-e éppen. Egy végtelen ciklusba vagy holtpontba keveredett program valószínű nem tudná magát biztonságos állapotba hozni még akkor sem, ha az oprendszerrel képes még kommunikálni.

    (A Windows Metro alkalmazások szüneteltethetők és hibernálhatók tetszés szerint, de ehhez az kellett, hogy ők teljesen más programozási modellt használjanak. Ez a modell több korlátot szab a programnak, pont azért, hogy az oprendszer jobban tisztában legyen vele, hogy épp mi történik.)
    Mutasd a teljes hozzászólást!
  • Én is ezt a kettőt akartam említeni, a végtelen ciklust, és az eseményre várást ami nem következik be.

    Az ember azt gondolná, hogy ma már nem is engedik, hogy valami 100% használja a procit, erőforrásokat hosszabb időn át, hanem kötelező jelleggel vissza kell adni a vezérlést a Windows-nak, illetve vissza veszi az erővel, és ha ilyen beragadt programot észlel akkor intézkedik, mondjuk kevesebb erőforrást ad neki, gond nélkül bezárja ha úgy kérem stb. Ez a rész még nem tökéletesen működik, túl udvarias még ma is a Windows.

    Vicces hogy pl a Firefox is 100% átadja a vezérlést egy oldalon lévő JavaScript kódnak, és ha az lefagy akkor a böngésző vissza sem kapja már, lefagy az egész. Elég nagy butaságnak tűnik ez, bár tudom hogy valószínűleg a gyorsabb futás érdekében van ez, de nem igaz hogy nem tud vele párhuzamosan futni egy nagyon rövid böngésző kód ami figyelné, hogy a JS vissza adja e a vezérlést a böngészőnek és ha hosszabb ideje nem tette akkor egyszerűen leállítaná.

    A Windows-ba raknék egy olyan fejlesztést is, hogy a program ablaka jelezhetné hogy az aktuális program mennyi erőforrást eszik, és gombnyomásra fel lehessen függeszteni a futást, majd később bármikor folytatni, esetleg felfüggeszteni majd kimenteni HDD-re hogy legközelebb arról a pontról lehessen folytatni.
    Mutasd a teljes hozzászólást!
  • A lefagyás meg sokszor a rossz memóriaelérés miatt van. Pl. nem lefoglalt területre írás stb..

    A nem lefoglalt területre írástól már kb. 20 éve összeomlanak a programok (kb. ennyi ideje futnak védett módban az oprendszerek). Ami sokkal több gondot okoz, az a lefoglalt területen a nem megfelelő dolog felülírása, de az meg kb. bármit okozhat a program viselkedésében, nem feltétlen lefagyást.

    A lefagyás két fő oka:
    1. Végtelen ciklusba került szál. A programozó azt hitte, hogy véges időn belül véget fog érni a ciklusa, de az adott környezetben soha nem következik be a kilépési feltétel.
    2. Holtpont (deadlock). A program valami olyan feltétel teljesülésére vár, ami soha nem fog bekövetkezni. Általában (de nem mindig) az okozza, hogy két egymástól független kód arra vár, hogy a másik csináljon valamit előbb.

    A kettő közt úgy lehet ránézésre különbséget tenni, hogy az első esetben az egyik processzormagod 100%-ra ki van hajtva, a másik esetben 0%-os az adott program CPU-használata.

    Jó, Linuxon a jogosultság kezelés miatt valóban necesebb vírusokat írni

    Jogosultságkezelés van ám Windowson is, nem rosszabb, mint Linuxon. Az ellen nem véd, ha a felhasználó rendszergazda joggal futtatja a vírust (mert mondjuk egy legitimnek tűnő telepítő program tartalmazza), pont ahogy a Linux se véd meg tőle, ha sudo-val futtatsz vírust. Az is igaz mindkét rendszeren, hogy a nem rendszergazdaként indított vírus még mindig vígan felülírhatja a személyes fájljait annak a felhasználónak, akinek a nevében éppen fut.
    Mutasd a teljes hozzászólást!
  • Azért a grafika nincs ingyen... Jó, mondjuk pl. a játékoknál maradva elég sok jól optimalizált motor van (pl. most nem rég játszottam ki nosztalgiából a F.E.A.R 3-at egy ősküveleten, és meglepően jól ment, de a Valve is jó cuccokat csinált).
    A lefagyás meg sokszor a rossz memóriaelérés miatt van. Pl. nem lefoglalt területre írás stb..
    Ezek egy része az oprendszer hibái miatt van, és legyen szó most a Windowsról. Lehet szidni hogy lefagy meg minden, de nézzük már meg mennyi mindent tud. Meg mindent erre írnak. Aztán lehet jönni a kamu érvekkel, hogy az Apple szoftverei meg sokkal biztosabbak. Ja, persze. Pont multkor olvastam egy cikket, hogy ott is terjednek elég keményen a vírusok. Jó, Linuxon a jogosultság kezelés miatt valóban necesebb vírusokat írni, de ha most a Linux lenne a Windows helyett, nem hinném, hogy sokkal kevesebb vírus lenne.. Sőt. Nehezebb dolga lenne a vírusírtónak.
    Na, kicsit elkanyarodtam a témától, meg nem írtam valami szépen, de szerintem reális szemszögből kommenteltem.
    Mutasd a teljes hozzászólást!
  • Szia!
    Nagy a hideg, attol!
    Na meg Windows alatt minden lefagy, kulonosen nyaron hasznos ez a tulajdonsag, mert a gep melle rakod a romlando cuccokat, es igy mindig hidegek maradnak.
    Mutasd a teljes hozzászólást!
  • Persze lejjebb van a max elerheto teljesitmeny (mikozben a fogyasztas meg sokkal sokkal lejjebb van), de ezt még tovabb fokozzak egy VM-el. Amikor egy tulsagosan designos weboldalt probalok megnezni, akkor csak ugy izzik a JavaScript engine ezen a VM-en. Ilyenkor egy linkre kattintasnal legalabb 5 masodpercig ott kell tartanod a kezedet a link felett es azon izgulni, hogy nehogy egy eppen betoltott reklam elcsusztassa azt a kezed alol.
    Eskuszom, a stock browser a kattintast nem esemenykent kezeli, hanem timerbol pollolgatja, hogy hol nyomod a touchscreent es ha nem jut szohoz az a timer, akkor aktivalodik a non-responsive UI technologia :D

    Na de ne fikazzak mar ennyit, a Dune II átirata peldaul remekul megy egy 25ezer forintos Androidos masinan is.
    Mutasd a teljes hozzászólást!
  • Nem vicceltem.
    Tényleg letud attól fagyni, mert túl melegszik....
    Mutasd a teljes hozzászólást!
  • De akkor föl kéne olvadnia :'D
    Így meg ha túlhül akkor kéne lefagynia ;)
    Mutasd a teljes hozzászólást!
  • Én ezt értem, csak azt nem, hogy mi használja el a memóriát.
    Valami ott nagyon számol a háttérben ami annyira lefoglalja az erőforrásokat?
    Mitől kell az Androidnak többet számolnia?
    Mutasd a teljes hozzászólást!
  • "akkor az mitől fagy le?"

    Túl melegszik.
    Mutasd a teljes hozzászólást!
  • Azert egy 1200Mhz-s ARM nagyon messze van egy 1200Mhz x86-tol.
    Mutasd a teljes hozzászólást!
  • iPhone - Android. Szerintem abbol adodik a kulonbseg, hogy az iPhone-nál csak 1 féle hardveren kell optimalisan megoldani az OS-t meg a programokat. Az Androidnal meg inkabb az a cél, hogy sokféle hardveren mukodjon. En is szidom, mint állat :D 1200MHz-s processzoron regen 2CD-s filmet tudtunk nezni annó 10-15 éve, ez meg egy 320x240-es youtube vidoetol megpusztul es olyan reszponziv lesz az UI, hogy 5 masodpercig kell taperolni, hogy reagaljon lol
    Mutasd a teljes hozzászólást!
  • Mi lenne, ha megegyeznénk a következőben: bizonyos kontextusban bizonyos hardware-elemek jelentősen csökkenthetik bizonyos effektusok erőforrásigényét. Kb ugyanazt jelenti, csak precízebb.
    Mutasd a teljes hozzászólást!
  • Ha a látványeffekt miatt lassú a program, akkor ott valami nagyon el van cseszve.

    Miért, szerinted mi lassít egy programot/játékot ha többek között nem az effektek? Főleg ha szoftveres a megvalósítás. De ha hardveres is, nem tudhatod hogy az adott eszközön pont azt nem bírja már.

    A "látványeffekt=szaggatás" tételre meg jó példa az összes FLASH játék, ahol nem bírják megállni hogy ne pakolják őket tele, azt hiszik a programozók, hogy az "ingyen van", a felhasználó meg csak azt látja, hogy a FLASH az lassú, pedig csak a programozó nemtörődöm.

    Egyébként ezer apró dolog számít. Az a gond, hogy ma már eleve sokszor nem tudja az ember, hogy mi zajlik a háttérben, lehet akaratlanul végez fölösleges munkát a program. Főleg ha kész játékmotort használ az ember. (Persze ha sajátot ír akkor is követhet el hibákat.)
    Mutasd a teljes hozzászólást!
  • Ha a látványeffekt miatt lassú a program, akkor ott valami nagyon el van cseszve.
    Mutasd a teljes hozzászólást!
  • > Hogy írjam meg én a saját programom Androidra, hogy a gyengébb hardverekkel működő eszközökön se legyen vele probléma?

    Ha lenne valami egyszerű szabály (pl minden vesszőspont után legyen szóköz), azt már mindenki alkalmazná, nem gondolod? Annyit tehetsz, hogy minél több készüléken teszteled a programod, és figyeled a gondokat.

    PS: És ha van valamilyen 'csicsa' a programban (másképp mondva: látványeffekt), azt tedd opcionálissá, vagy még inkább szedd ki belőle.
    Mutasd a teljes hozzászólást!
  • Például azért, mert kevesebb memória jut a programnak és ezért folyamatosan lapoznia kell az operációs rendszernek.
    A háttértár pedig sokkal lassabb, mint a RAM.

    Ha maga az operációs rendszer akadozik (vagyis a legalapvetőbb programok is), akkor 100-ból 99x a túl kevés memória az ok.

    Egyébként így van ez az Android/iOS kérdéssel is...
    Az Android sajnos nincs annyira jól kioptimalizálva, mint az iOS, ezért több memóriára (és számítási kapacitásra) van szükség az ugyanolyan folyamatos működéshez.
    Mutasd a teljes hozzászólást!
  • Sziasztok:)

    Elég közönségesen hangzik a kérdés, de fel merült bennem, hogyha van egy operációs rendszer (például Windows) akkor az mitől fagy le, mitől akadozik?

    Másik példa:
    Adott egy igen szép grafikájú játék ami IPhone-on tökéletesen száguld, ám ugyanez a program Androidon (erősebb hardverrel is) néha akadozva lassan fut esetleg le is áll.
    Ez mitől van? Miből adódik ekkora különbség, hisz' a két programnak ugyanaz a forrása is.

    Fejlesztői kérdés:
    Hogy írjam meg én a saját programom Androidra, hogy a gyengébb hardverekkel működő eszközökön se legyen vele probléma?
    Mutasd a teljes hozzászólást!
abcd