Dotaz: Presnost metody Sleep v Jave?

[pete]

Programujem hru pod Javou(eclipse, linux mandriva 2007) a pre uspanie pouzivam metodu Thread.Sleep. Problem je v tom ze pri 1ms sa program uspi na 5ms, z toho mi vypliva ze najmensie rozlisenie je 5ms. Da sa to nejak obist?... Potreboval by som presnost na 1ms...

Odpovědi

[thingie]

No, nejsem si jistý, jestli to má přesně vliv, ale zkusil bych v jádře nastavit volbu HZ na 1000.

[thingie]

(což samozřejmě nebude fungovat pro lidi, kteří si vlastní kernel kompilovat nechtějí (výchozí volba je 250, to by mohlo těm pěti ms zhruba odpovídat), měl by ses obejít bez toho)

[pete]

Nedalo by sa to nejakym sposobom obist aj mimo jadro?.. Alebo nastavenim v JVM?

[thingie]

Jaké výsledky dostáváš pod Windows nebo jiným systémem?

Javadoc popisuje, že chování je závislé na systémových časovačích a plánovačích. Takže snadno to obejít asi nebude lehké, pokud to bude vůbec možné.

[thingie]

Jinak, když zkusím Google, přesností sleepu se zabývají zejména audio aplikace. Nevím, proč by si hra s přesností na jednu dvě desítky milisekund nevystačila.

[cronin]

Asi Ta nepotesim, ale nebude to fungovat.

Kazdy operacny system updatuje svoj cas, ktory prezentuje user space-u, s urcitou granularitou. Tato granularita je radovo v desiatkach milisekund. T.j. cas sa nemeni milisekundu po milisekunde, ale dajme tomu kazdych 20 milisekund sa zvysi o 20 milisekund. Inak povedane, metoda System.currentTimeMillis() bude 20 milisekund vracat to iste cislo. Navyse, ten interval nie je vzdy rovnaky. Pred casom sme robili testy spravania sa operacnych systemov v tomto ohlade, a dosli sme k nasledovnemu: FreeBSD v priemere updatovalo cas vo velmi castych itervaloch (menej ako 10 milisekund), ale malo velky rozptyl v itervaloch updatov (az do 100 milisekund). Linux mal updaty pomalsie (20 - 30 milisekund), relativne stabilne. Windows updatoval takmer vylucne po 15 alebo 30 milisekundach. Solaris 9 aj 10 mal v priemere itervaly najdlhsie, ale velmi stabilne, okolo 40 milisekund, presne cislo si nepamatam.

Toto spravanie sa asi da ovplyvnit konfiguraciou kernelu toho ktoreho systemu. V reale ale sleep kratsi ako niekolko desiatok milisekund nema zmysel.

Btw, pod akou verziou Javy robis? Ak pod 1.4, tak si rozbal src.zip a pozri si, ako pracuje metoda java.lang.Object.wait(long, int). Budes prekvapeny. Neprijemne prekvapeny. Ale ziskas realisticky pohlad. Hold, od real-time OS sme este daleko.

[cronin]

Nasiel som vysledky, takze casy updatov:

SunOS 5.9/5.10      : 10ms
Linux 2.4.21        : 20ms
Windows 2003 Server : 16ms
FreeBSD 6.0         :  2ms

Opravujem este jeden udaj: najstabilnejsie intervaly boli v pripade Linuxu.

[pete]

Tak taku dlhu odpoved som necakal :)... dika..

Spominal si System.currentTimeMillis()... A k tomu by som mal dotaz : A co funkcia System.nanoTime() od verzie 1.5?... Ta vracia cas v nanosekundach. A pocitam s tym ze to nevracia System.currentTimeMillis()*1000000.

[cronin]

System.nanoTime() je v Jave 5 nativna, takze podla javovskych zdrojakov sa neda povedat, co robi skutocne. Chcelo by to pozriet sa na zdrojaky JVM:

public static native long nanoTime();

Definicia Object.wait(long, int) sa nezmenila:

public final void wait(long timeout, int nanos) throws InterruptedException {
        if (timeout < 0) {
            throw new IllegalArgumentException("timeout value is negative");
        }

        if (nanos < 0 || nanos > 999999) {
            throw new IllegalArgumentException(
				"nanosecond timeout value out of range");
        }

	if (nanos >= 500000 || (nanos != 0 && timeout == 0)) {
	    timeout++;
	}

	wait(timeout);
    }

Takze ak to ma nanosekundy vacsie ako 500000, tak zvysi wait o milisekundu. Ak to ma nanosekundy nenulove a milisekundy nulove, waituje to aspon obligatnu jednu milisekundu.