---

Er det muligt at sende et objekt til flere sockets på samme tid - lidt i
stil med et multicast på et netværk?
Jeg har fire sockets, som gerne skal have tilsendt et objekt på samme
tid, og tænker at der må være en smartere måde end at løbe et array
igennem og sende til hver enkelt.

Mvh
Kenneth

---

Java har ikke asynkron IO og du kan dermed ikke sende et objekt over
forskellige sockets paa samme tid.
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.

class ObjectWrapper { public Object o; }
class ObjectSender extends Thread {
public final init(final ObjectWrapper _ow, final Socket theSocket) { ow
= _ow; } // + setup ObjectOutputStream
public void run() { out.writeObject(ow.o); }
}

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.

du kan herefter skrive
objectWrapper.o = someObject
threadGroup.interrupt();

de x antal threads vil herefter blive vaekket hvorefter de sender object o
ud paa de forskellige sockets. Metoden er kun
god hvis du har flere processorer eller et skidt netvaerk. Den bliver ekstra
god hvis du gentagende gange skal sende
objekter, da det jo blot drejer sig om to kode-linjer pr. gang.


Lars.


"Kenneth Ahn Jensen" <kaj@itu.dk> wrote in message
news:3AF94E5C.E97BA49@itu.dk...
> Er det muligt at sende et objekt til flere sockets på samme tid - lidt i
> stil med et multicast på et netværk?
> Jeg har fire sockets, som gerne skal have tilsendt et objekt på samme
> tid, og tænker at der må være en smartere måde end at løbe et array
> igennem og sende til hver enkelt.
>
> Mvh
> Kenneth
>

---

"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

---

"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
>
>
>

---

Steffen Enni wrote:

> 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.)

Det er implementationsafhængigt. Ved "green threads" er det JVM'en selv
der implementerer trådningen (og den kører i sagens natur på én CPU).
Ved native threads afhænger det af implementationen - Solaris og Irix
JVM'erne understøtter flere CPU'er. Jeg mener også at IBM's Linuxport
kan.

> Skidt løsning. Lav en synkroniserings variabel. Eksempelvis: Object x =
> new Object(). Trådene siger så synchronized(x) { x.wait(); }

Vær herudover opmærksom på at meget få objekter som standard i Java er
synkronized fordi det er tungt - specielt ved multi-CPU systemer
(variablen kan ikke caches på de enkelte cpu'er).

--
Thorbjørn Ravn Andersen "...plus...Tubular Bells!"
http://bigfoot.com/~thunderbear