"For multithreaded code with little synchronization and several runnable
threads at a given time, only the native threads version will take advantage
of a multiprocessor. It will be much faster as a result."
http://web.mit.edu/java_v1.1.5/distrib/sgi_63/webdocs/native_threads.html
"java -native someprogram" vil mappe normale threads i "someprogram" til
native threads og vil derfor blive skeduleret ud over flere processorer. Jeg
har da personligt oplevet mange gange en stor forbedring naar jeg koerte paa
en multiprocesser maskine med -native i forhold til at bruge green threads.
Proevet paa Solaris og Irix maskiner. Windows goer det automatisk da der
ikke findes green threads paa Windows platformen.
Lars
"Steffen Enni" <enni@zachosw.dk> wrote in message
news:9devd4$17j2$1@news.cybercity.dk...
>
> "Lars Rosenberg" <latex_rules@hotmail.com> wrote in message
> news:pQAK6.2163$h4.549737@news101.telia.com...
> > Du kan lave en slags simulering ved at bruge threads som sender et
objekt
> i
> > run metoden.
> > Hvis programmet koeres paa en maskine med flere processorer kan du opnaa
> en
> > forbedring ellers ikke.
>
> Det afhænger af hvilken arkitektur du kører på. På de arkitekturer jeg
> mener at kende, er det lige omvendt. Der forholder det sig således:
>
> Multithreading afvikles på den samme processor. Så isoleret set, er der
> ingen fordel ved at afvikle et multitrådet program på en n (>1) processor
> arkitektur. Fordelen ved n (> 1) processorer er at der så kan afvikles
> flere parallelle processer. Som eksempel kan jeg nævne Compaq NonStop
> Himalaya Servere, hvor en JVM er bundet til en processor. (Og jeg mener
at
> det samme gør sig gældende på WindowsNT/2000 på Intel, Compaq Tru64 Unix
på
> Alpha og Sun Solaris på SPARC, men jeg er ikke skråsikker.)
>
> Ved at parallellisere I/O i flere tråde, gives processoren mulighed for at
> lave tråd-skifte til en anden tråd mens der ventes på I/O. Man vil derfor
> opleve en forbedring i mange tilfælde. Det afhænger dog af flere
faktorer:
> Processorens overhead ved at lave et tråd-skifte, I/O hastigheden samt
> overheadet ved at starte en ny tråd op (hvis den ikke allerede er der og
> venter på at blive sluppet løst). Specielt det sidste afhænger meget af
> arkitekturen. Som hovedregel kan det dog godt svare sig at lave asynkron
> I/O som Lars beskrev det.
>
> > smid i x antal ObjectSender ned i en ThreadGroup og aendre run-metoderne
> saa
> > de kun sender hvis de blev
> > interrupted midt i et sleep(100000) kald.
>
> Skidt løsning. Lav en synkroniserings variabel. Eksempelvis: Object x =
> new Object(). Trådene siger så synchronized(x) { x.wait(); }
>
> Og en af dem vækkes til live af en anden tråd med x.notify(). (Brug for
> guds skyld ikke notifyAll()...)
>
>
> Venlig hilsen,
>
> Steffen Enni
>
http://www.zachosw.dk
>
>
>