---

Jeg her en klasse, der er nedarvet fra Thread klassen. Basalt kan
klassen lave 2 forskellige typer bergeninger A og B, der begge er
parameter styret.

Jeg ønsker at have n instancer af klassen.

Først sættes de n objeketr til at udføre begening af type A (med
forskelige parametre). Når alle objekterne er færdige med det skal de
sættes til at lave beregninger af type B. Nå de igen er færdige skal
starte forfra med type A etc.

Er der nogen som har nogen forslag til, hvordan man skal styre det?


Med venlig hilsen
Torben

---

On Fri, 23 Jun 2006 13:25:10 +0200, torben wrote:

>
> Er der nogen som har nogen forslag til, hvordan man skal styre det?
Da det, du skikserer, er en 100% sekventiel opførsel, hvorfor så anvende
tråde?

Det nemmeste ville da være
sålænge der ikke skal stoppes
beregn A;
beregn B;

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen <mir@miras.org> writes:

> Da det, du skikserer, er en 100% sekventiel opførsel, hvorfor så anvende
> tråde?

Det kunne velsagtens være fordi beregningerne med fordel kan laves
parallelt så længe man holder sig indenfor samme type.

--
Jacob

---

torben <torben@frojonck.dk> writes:

> Jeg her en klasse, der er nedarvet fra Thread klassen. Basalt kan
> klassen lave 2 forskellige typer bergeninger A og B, der begge er
> parameter styret.
>
> Jeg ønsker at have n instancer af klassen.
>
> Først sættes de n objeketr til at udføre begening af type A (med
> forskelige parametre). Når alle objekterne er færdige med det skal de
> sættes til at lave beregninger af type B. Nå de igen er færdige skal
> starte forfra med type A etc.
>
> Er der nogen som har nogen forslag til, hvordan man skal styre det?

Jeg ville maaske kigge paa de nye LinkedBlockingQueue eller lign., der
er er udemaerket eksempel i javadok'en:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html

Hvor "kommer" parametrene fra? Er det en begraenset maengde, eller
uendeligt? Hvis det var en kendt maengde input kan du evt fylde
koeen op med den korrekte sekvens af input parametre.

Mvh,
Soren

---

Soren (News) wrote:
> torben <torben@frojonck.dk> writes:
>
>> Jeg her en klasse, der er nedarvet fra Thread klassen. Basalt kan
>> klassen lave 2 forskellige typer bergeninger A og B, der begge er
>> parameter styret.
>>
>> Jeg ønsker at have n instancer af klassen.
>>
>> Først sættes de n objeketr til at udføre begening af type A (med
>> forskelige parametre). Når alle objekterne er færdige med det skal de
>> sættes til at lave beregninger af type B. Nå de igen er færdige skal
>> starte forfra med type A etc.
>>
>> Er der nogen som har nogen forslag til, hvordan man skal styre det?
>
> Jeg ville maaske kigge paa de nye LinkedBlockingQueue eller lign., der
> er er udemaerket eksempel i javadok'en:
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html
>
> Hvor "kommer" parametrene fra? Er det en begraenset maengde, eller
> uendeligt? Hvis det var en kendt maengde input kan du evt fylde
> koeen op med den korrekte sekvens af input parametre.
>
> Mvh,
> Soren

Tak, det vil jeg kigge nærmere på. Det ser ud tl at kunne bruges.

Torben

---

torben <torben@frojonck.dk> posting:

>forskelige parametre). Når alle objekterne er færdige med det skal de
>sættes til at lave beregninger af type B. Nå de igen er færdige skal
>starte forfra med type A etc.
>
>Er der nogen som har nogen forslag til, hvordan man skal styre det?

Lyder som om, du skal have fat i en standardbarrier til at holde
styr på beregningsafslutningerne, og sådan en er tilsyneladende
impl. i Java 1,5:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CyclicBarrier.html

--
What is life, except excuse for death,
or death, but an escape from life. -Ukendt

LOL - http://www.sofastitsings.com/commercial.html

---

Christian Bohr-Halling wrote:
> torben <torben@frojonck.dk> posting:
>
>> forskelige parametre). Når alle objekterne er færdige med det skal de
>> sættes til at lave beregninger af type B. Nå de igen er færdige skal
>> starte forfra med type A etc.
>>
>> Er der nogen som har nogen forslag til, hvordan man skal styre det?
>
> Lyder som om, du skal have fat i en standardbarrier til at holde
> styr på beregningsafslutningerne, og sådan en er tilsyneladende
> impl. i Java 1,5:
> http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CyclicBarrier.html
>

Tak, det ser også ud til a være en mulighed.

Torben

---

torben <torben@frojonck.dk> writes:

> Jeg her en klasse, der er nedarvet fra Thread klassen. Basalt kan
> klassen lave 2 forskellige typer bergeninger A og B, der begge er
> parameter styret.

Hvor kommer denne projektbeskrivelse fra?

Mht trådsynkronisering er emnet beskrevet i Java Tutoriallen

http://java.sun.com/docs/books/tutorial/essential/threads/multithreaded.html
--
Thorbjørn Ravn Andersen

---

Thorbjørn Ravn Andersen wrote:
> torben <torben@frojonck.dk> writes:
>
>> Jeg her en klasse, der er nedarvet fra Thread klassen. Basalt kan
>> klassen lave 2 forskellige typer bergeninger A og B, der begge er
>> parameter styret.
>
> Hvor kommer denne projektbeskrivelse fra?

Hvad mener du? Mit problem er som Jakob i et tidligere indlæg nævnte, at
jeg har 2 processtrin a og b. Trin a kan med fordel løses parallelt
(især hvis man har en CPU med hypertreading eller flere processorer) og
tilsvarende kan b løses psrallelt. Men processen b må ikke påbegyndes
før a er færdig.

Hvis det kan løses uden brug af trådet processer er jeg meget
intereseret i at høre hvordan.
>
> Mht trådsynkronisering er emnet beskrevet i Java Tutoriallen
>
> http://java.sun.com/docs/books/tutorial/essential/threads/multithreaded.html

Ja, den har jeg kigget på. Men jeg synes ikke jeg kan "konvertere" deres
producer-consumer eksempel til noget brugbart.

Men det ser ud til, at der i verson 5 af Java er gode muligheder for det
jeg gerne vil opnå.

Torben

---

torben <torben@frojonck.dk> writes:

> > Hvor kommer denne projektbeskrivelse fra?
>
> Hvad mener du? Mit problem er som Jakob i et tidligere indlæg nævnte,
> at jeg har 2 processtrin a og b. Trin a kan med fordel løses parallelt
> (især hvis man har en CPU med hypertreading eller flere processorer)
> og tilsvarende kan b løses psrallelt. Men processen b må ikke
> påbegyndes før a er færdig.

Det lød for mig som en skoleopgave - deraf formuleringen.

Producer-consumer kan generaliseres til at hver arbejdertråd henter en
jobbeskrivelse hos en master-tråd og udfører det beskrevne stykke
arbejde.

Mastertråden holder så styr på hvornår der ikke er flere hhv A og B
opgaver.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn/