[linux-l] Debian-Mirror der belug...

Tobias Schlottke toby at schlottke.net
Fr Okt 17 16:38:13 CEST 2003


On Fri, 17 Oct 2003, Jan-Benedict Glaw wrote:
> Wie bitte? Java ist doch interpretiert, ja? Ich würde eher vermuten, daß
> dafür so 100..5000 CPU cycles verbrannt werden.

Na und?
Die VM Spezifikation beschreibt eine CPU. Und die wird
emuliert. Guck Dir die mal an. Da gibt es wunderschöne
Befehle, die genau das tun. Vor, während und nach dem
Interrupt hat die CPU einen wohldefinierten Zustand.
Entweder ist es verändert oder eben nicht.

> Selbst, wenn das innerhalb zweier CPU-Befehle gemacht werden würde (ja,
> selbst wenn Du ein decrement direkt auf einer Variable machen könntest)
> kann das noch sauber danebengehen. Denk mal an ein nonCC-System...
Was meinst Du mit nonCC?

> > Entweder der Int kommt vorher oder nachher. Zugegeben,
>
> Oder mittendrin oder nie.
?? Wie willst Du den bitte ohne Ints Multithreading
implementieren? (Den Unfug mit "kooperativem
Multithreading" a la Win3.11 mal außen vor)

> > ist nicht ganz sauber. Wenn der Compiler daraus mehr
> > als eine Instruktion braucht, kann's scheppern. (Nein,
> > _muß_ es scheppern ;-)
>
> Falsch. Es scheppert schon, selbst, wenn es nur eine Instruktion ist.
> Trenne Dich von dem Gedanken, daß, (C-isch) "*i = 5;" sofort und für
> alle sichtbar den Speicher, auf den i zeigt, auf 5 setzt. Bestenfalls
> sieht die CPU, die das getan hat, es sofort. Bei Intel sehen's auch andere
> CPUs. Aber das stimmt nicht für viele andere Systeme...

Ja, bei mehreren CPU's hast Du recht. Mmmm. Bei Intel
müßte es gehen, der macht AFAIK nen Buslock.
(Außerdem hat meine Büchse nur einen Denker)

Aber las uns dochmal lieber andersrum rangehen. Was
passiert denn wenn mehrere CPUs asynchron am Zähler
rumpopeln. Im schlimmsten Fall hab ich ein paar Threads
zuviel gestartet und mein Test ermittelt eine zu lange
Zeit. Ich fand 2-300 ms für 1000 Threads schon ganz
schön schnell.

Toby




Mehr Informationen über die Mailingliste linux-l