Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Fork-Join razvoj u Java™ SE


Fork-Join razvoj u Java SE

Fork-Join za svakodnevne, multi-core Java Java™ aplikacije

Forking ili cepanje posla u više zadataka za obradu i paralelno spajanje rezultata je tehnika koja se koristi u brojnim naučnim aplikacijama za deljenje u manje količine. Mnoge druge aplikacije mogu da imaju koristi od fork-join obrade ali korišćenje naučnog pristupa možda nije u njihovom najboljem interesu.

Ovaj članak predstavlja "sramotnu paralelu” fork-join pristupa koji radi dobro za svakodnevne, multi-core aplikacije u Java ™, SE, ME kao i Android. ™ (3000 reči)

Edward Harned (eh at coopsoft dot com)
Viši programer, Kooperativnii Softver Sistemi, Inc
februar, 2010 [ažurirano avgust 2011.]

Šta je Fork-Join?

Zamislite fork na putu gde se svaka staza na kraju ponovo spaja - pridružuje.

Fork-Join razbija aplikaciju u nekoliko delova za paralelno procesiranje i pridružuje rezultate na kraju.

Slika 1: Struktura Fork-Join

Fork-Join Structure

Recimo da imamo niz od hiljadu brojeva. Moramo da uradimo proceduru za svaki od ovih brojeva i dodamo ukupnu sumu.

1. lista: Red procesa

 
 
for (int i = 0; i < 1000; i++) {
      total += doProcedure(array[i]);
  }

Ako postupak traje sekund (prema zidnom satu) da se završi, onda će trebati hiljadu sekundi (preko 16 ½ minuta) da izvrši zadatak.

Fork-Join bi mogao

  • odvojiti(raspodeliti) veliki niz u deset nizova od sto elemenata, svaki
  • obraditi svaki niz na posebnom procesoru, i
  • pridružiti rezultate kada završi.

To bi potrajalo sto sekundi (nešto više od 1 ½ minute), jedna desetina od prvobitnog. Što više procesora na raspolaganju, brži je rezultat.

To je ono što predstavlja naučno računanje -obradu ogromnih količina podataka na onoliko procesora koliko je dostupno. Ova apstrakcija podseća na standardni naučni model podeli-i-vladaj (Divide-and-Conquer).

Divide-and-Conquer je prirodna paradigma za paralelne algoritme. Posle podele problema na dva ili više pod-problema, metod rešava pod-probleme istovremeno. Tipično, pod-problemi se rešavaju rekurzivno tako da je sledeći korak podela na još više pod-problema za rešavanje u paraleli.

Slika 2: Divide-and-Conquer

Divide and Conquer

Problemi sa korišćenjem Fork-Join naučnog modela za svakodnevne aplikacije

Kreiranje zadataka nije problem, oni su samo predmeti. Problem je veliki broj povezivanja koja obrađuju poslove kada je to zadacima potrebno:

Veze
Pristup udaljenim uslugama (DBMS, porukama, i mnogim drugim) zahteva vezu sa udaljenim servisom. Generalno, te usluge koristite vezu da bi uspostavile konekciju a za to je potrebna memorija, kontekst prebacivanja, sinhronizacija i koordinacija. Što više veze sa servisom, više resursa je potrebno servisu, a manje veza na raspolaganju za druge poslove u JVM. To utiče na svakog korisnika.

Brave
Brave su ubice za visok učinak. Neispravne / ispravne brave, prioritet inverzije, izgladnjivanje, praćenje i opšti troškovi ( koji eksponencijalno rastu sa dužinom liste čekanja zadataka) su neki od problema korišćenja brava.

Semafori
Što je više veza koje žele istovremenu dozvolu, više veza mora da čeka na dostupnu dozvolu. To nas vraća na sve probleme korišćenja brave.

Cache koherentnost
Kada više procesora pristupa / ažurira iste promenljive unutar cache linije, (blokiranje podataka kopiranih iz glavne memorije koja sadrži mnogo oblasti), jedinica memorije može da poništi cache liniju. To ne samo da usporava aplikaciju, može da utiče i na druge aplikacije.

Velika memorija
Što više objekata ili što veći objekti, veća memorija.Što više aktivnih veza koje rešavaju zadatke, onda veća memorija. Naravno, tome sledi da je zadacima velike memorije potrebno izbegavanje gušenja.

Potreba za lepom igrom
Vaša aplikacija možda neće biti jedina aplikacija koja je pokrenuta na računaru. Kada jedna aplikacija zgrabi resurse, svako oseća pritisak. Lepo igranje sa drugima nas vraća na ono što smo svi naučili u detinjstvu. Isto važi i kada se razvija softver koji ne radi kao samostalna aplikacija.

Tema multi-core razvoja je da sačuva tvrdnju, zadatke koji se takmiče za ista sredstva, na minimumu.

Ako paradigma dinamične dekompozicije Divide-and-Conquer odgovara vašim potrebama, onda pročitajte ovaj članak o visokoj performansi DSE verzijeTymeac-a. Inače funkcionalni forking okvir može više da odgovara vašim potrebama.

Funkcionalna forking okvir

Java ™ SE / ME multi-core aplikacije, kao i Android ™ aplikacije koje ne mogu da koriste Divide-and-Conquer model, ne obrađuju velike nizove brojeva, ili nemaju intenzivne računarske strukture koje su potrebne funkcionalnom forking okviru za paralelne aplikacije. Konkretno, oni moraju da podele rad u svoje funkcionalne komponente, a ne da razlažu u niz istovetnih pod-zadataka.

Slika 3: Funkcionalni forking okvir

Functional Forking Framework

Funkcionalni forking okvir ima dve osnovne osobine. On mora da:

  • ograniči tvrdnju
  • bude jednostavan za korišćenje ili poređenje.

Ograničavanje tvrdnje

Održavanje broja aktivnih, konkurentskih veza na minimum je glavni zadatak. Najlakši način da se ograniči tvrdnja je da se koriste pragovi za svaku vezu koja se servisira u red zadataka. Pogledajte ovaj članak na Glavni prioriteti visoke performanse u Java SE kao primer kako pomoću liste čekanja možete da očuvavate resurse veza.

Ponovno korišćenje resursa umesto dobijanja novih kopija resursa je bolja kombinacija. Moramo uzeti u obzir ne samo kod zadataka, već i kod resursa upravljanja.

Uzmimo primer zadatak kome je potreban pristup bazi podataka koja zahteva [java.sql.]statement. Korišćenjem niza zahteva, kod zadatka može da deli istu izjavu za mnoge prilaze, a da ne dobija novu izjavu za svaki pristup. Deljenje izjave je ogromna ušteda u opštim troškovima i ograničava tvrdnja okviru koda upravljanja.

Šta je “sramotna paralela”?

Sramotno paralelni algoritmi su oni koji mogu da reše mnoge slične, ali nezavisne zadatake istovremeno, bez ili sa malo potrebe za koordinacijom između zadataka. Ovakvi problemi imaju tako laku paralelizaciju da je nekome skoro "neprijatno" da govori o tome kako je jednostavno da se dobije više procesora koji efikasno rade.

Rešenje ovakve paralele može lako da se izdvoji u više potpuno nezavisnih komponenti, gde se svaka izvršava na posebnom ​​procesoru.

Slika 4:. Sramotna paralela

Embarrassingly Parallel

Na primer:
Možda će biti potreban automatizovani sistem cena. Za njegovo razvijanje, sistemu je potrebna osnovna cena proizvoda (cena baze podataka), popust kupca za proizvode i špediciju ( baza podataka klijenta), i osnovne troškove isporuke ( baza podataka špeditera.)

Tradicionalno,program pristupa serijski svakoj bazi podataka, čekajući da se svaki pristup završi pre nego što pređe na sledeći pristup.

U paralelnom sistemu, program deli zahtev u tri reda, svaki opslužuje thread pool, čeka da završi poslednji pristup i pridružuje () rezultate zajedno.

Slika 5: Cena kvote

Cena kvote koja se nalazi iznad je primer sinhronizovanog zahteva, gde pozivalac čeka završetak. To je samo mali korak napred da bi se dodala podrška za asinhroni ili autonomni zahtev, kada pozivalac ne čeka završetak.

Postoje mnoge, mnoge situacije u kojima je podela rada na komponente poželjna:

  • Uzmite aplikacije igre u kojoj možemo podeliti događaj u odvojene komponente. Ovde je prednost uzbuđenje, više segmenata događaja koji se odvijaju istovremeno, i igra je zanimljivija
  • Uzmite aplikaciju sa više animacija, gde možete da izdvojite svaku animaciju da radi na svom procesoru
  • Uzmite jednu operaciju za obradu slika, gde svaki piksel na slici mora da ima promenjenu boju. Okvir može lako distribuirati podatke slike na više zadataka koji mogu da rade nezavisno jedan od drugog.
  • Uzmite finansijsku instituciju u kojoj ponovo vrednovanje portfolia uključuje komponente koje komuniciraju sa različitim tržištima širom sveta.
  • Uzmite aplikaciju zdravstvene zaštite u kojoj su razni testovi komponente u dijagnostici.

To je nastojanje da se vidi samo zašto aplikacija ne može koristiti paralelizaciju sa funkcionalnim forking okvirom.

Kako bi ovaj okvir izgledao na Java ™ aplikaciji?

Okviru za račvanje zahteva u njegove funkcionalne komponente je potrebno da:

Poznaje komponente (redove) za svaku zatraženu operaciju (funkciju). Jednostavna klasa koja sadrži niz imena funkcije i spisak povezanih redova je osnovno Java ™ programiranje.

Lista 2: Funkcijska klasa

 
 
public class Function {

      private String    name; // Function name
      private Queue[] que;   // Queues for this Function
  }
 

Postavite zahtev (koji sadrži ulazne objekte) u svakom od redova vraćajući niz objekta na pozivaoca ili ignorišite vraćene objekte.

Lista 3: Postavite u red

 
 
public Object[] fork(Queue[] que, Object request) {

      Object[] return_obj = new Object[] {null, null, null};

      for (int i = 0; i < que.length; i++) {
           putInQueue(que[i], return_obj [i], request);
      }

       return return_obj;
}
 

Sačekajte završetak / tajm-aut ili nemojte čekati.

Lista 4: Čekati / ne čekati

 
 
public boolean join(Object[] obj) {

    /* when all elements are non-null, return true
     * wait for a while
     * after an interval, return false
     */

  }
 

Vratite rezultate pozivaocu ili ignorišite objekte

slika 6: Povratak na pozivaoca

Return Object[]

 

 

 

 

 

Da bismo izgradili ovaj okvir:

  1. Trebalo bi održati stvarni broj zadataka koji radi
  2. Trebalo bi održati spisak redova i funkcija
  3. Trebalo bi održati "start up" klasu koja učitava redove i funkcije u memoriju

(1) Kod koji izvršava posao bi trebalo da izgleda ovako:

Lista 5: Radni kod

 
 
public static Object main(Object obj) {}
 

Glavni () metod koji prihvata objekat (ulaz od pozivaoca) i vraća objekat (rezultat rada.)

(2) Mogli bi da održimo redove i funkcije kao objekte u okviru jednostavne klasne liste

(3) Start up može jednostavno da učita klasne liste u memoriju sa novom (klasnom listom) i pokrene veze za svaki red.

Kako bi mogao da izgleda jednostavan poziv:

Lista 6: Jednostavan poziv

 
    Framework
fw = new Framework();

    // For each call:
    Function
func = fw.getFunction(name);
    Object[] back =
func.fork(request};
 

Ovaj okvir je jednostavan za korišćenje, sramotno jednostavan.

Pregled

Do sada, smo videli kako podela zahteva u njegove funkcionalne komponente može da funkcioniše kao ugrađeni deo jedne aplikacije (u okviru istog JVM.) Da bi bili praktični, potrebno je da napravimo okvir koji je pristupačan iz drugih JVM-a. Jednostavno, on mora da podržava mnoge korisničke pozive istovremeno kao server.

Napraviti server

Koje promene moramo učiniti da pretvorimo ovaj jednostavan okvir u server?

  1. Moramo odvojiti pozivaoca od posla.
  2. Moramo obezbediti oporavak greške.
  3. Moramo podržati okvir kao udaljeni objekat.
  4. Moramo obezbediti sigurnost.
  5. Moramo obezbediti administrativnu funkcionalnost za kontrolu servera.


Razdvajanje
Prva promena je razdvajanje zahteva posredovanjem (to je gornja fork () metoda) od stvarnog procesa. Moramo da ih odvojimo, ali i da ih pratimo, svaki zahtev u jedinstvenom objektu.

Lista 7. Zahtev objekta

 
  private long              unique_id; // unique identification of this request
  private Object           input; // input reference, if any
  private boolean         type; // type of request true=sync false=async
  private Object[]         output // the output objects from the tasks
  private AtomicInteger next_output; // subscript to add an element to above
  private Queue[]         que_names; // list of all the queues in this function
  private Queue            agent; // future queue, if used
  private AtomicInteger nbr_remaining; // queues remaining to be processed
  private int                wait_time; // max wait time for sync request
 

Šta je polje "agent?"

Agent
Sinhronizovani zahtev vraća objekatski niz od procesa do pozivaoca. Šta bi trebalo da uradi okvir sa vraćenim nizom objekta iz asinhronog zahteva? Okvir opciono može staviti niz objekta (kao input) u novi red za obradu zadatka agenta. Na ovaj način je zadatak agenta može da preduzme mere na osnovu završetka statusa prethodnog procesa.

Na primer:
Funkcija je da se stvori kvota cene i da se pošalje korisniku kao asinhroni zahtev.

  1. Pozivalac koristi asinhroni fork () metod.
  2. Okvir deli zahtev u dotične redove.
  3. Kada se poslednji red završi, okvir prolazi niz vraćenog objekta na zadatku agenta stavljanjem zahteva u red navedenog kao "agent".
  4. Zadatak agenta šalje mejl nevraćajući ništa.

Ispravljanje greške
Druga promena je dodavanje ispravljanja greške, znak profesionalizma.

Šta može da pođe naopako ovde? "Sve što može da pođe naopako će poći naopako." Marfijev zakon.

Izlazak
Mozemo da imamo grešku u podeli. Ograničeni red može biti pun ili bi mogao biti onemogućen (više u tekstu ispod). Ispravka greške bi trebala da podrži sve redove koji uspešno račvaju i obavestiti pozivaoca problema. Na primer:

  • Imamo tri reda (A, B, C) u funkciji.
  • Redovi A i B uspešno primaju zahtev
  • Red C ne uspeva da primi zahtev, jer je red pun
  • Sada idemo unazad pokušavajući da povučemo zahtev iz svih redova koji se račvaju uspešno tako da možemo da uštedimo vreme obrade zahteva za neispravne zahteve.

Izuzetak / Greška
Mogli smo da imamo izuzetak / grešku u stvarnom kodu zadatka koji izvršava posao. Ako jednom nije uspeo, verovatno neće ponovo uspeti. Zbog toga je preporučljivo da se onemogući red dok programer ne ukloni problem. Kada je kod zadatka čist, ne želimo da se skine server. Želimo da obavestimo server da imamo novu kopiju radnog koda koji je čist i želimo da omogućimo red.

Odugovlačenje
Ovo gore se moglo desiti u asinhronizovanom zahtevu, nazivamo ga stall-odugovlačenje (sinhronizovani zahtev prestaje i može da se očisti iz sistema). Pošto funkcije ne mogu biti završene dok se ne završe svi redovi, treba da postavimo zahteve odugovlačenja u listu odugovlačenja. Kada je red ponovo upotrebljiv, možemo ponovo da počnemo procesuiranje sa liste odugovlačenja.

.
Brisanje je tema za sebe i zahteva obuzdavanje veze. Ovaj članak predstavlja: Upravljanje vezama u Java SE

Dileme veze
Mogli bismo da imamo zauvek zastoj veze na spoljnom izvoru, ili idite do beskrajne petlje. U svakom slučaju, od vremenskih događaja u životu veze, okvir može da prepozna ovu situaciju, a može izbrisati vezu i zameniti je novom vezom.

Otkazivanje
Mogli bismo da imamo pozivaoca koji želi da otkaže ranije podnešen zahtev. Otkaz je sličan tajm-aut grešci, ali primenljivo je i za sinhroni i asinhroni zahtev. Iako je otkazivanje zahteva najpoželjnije, logika za izvršavanje otkazivanja u multi-komponentnom zahtevu nije za one sa slabim srcem.

Praćenje
Vreme je beskorisno osim kada daemon veza prati vremenski događaja u potrazi za aktuelnim ili potencijalnim problemima.

Obaveštenje
Ni jedan okvir ne može da obradi svaku situaciju, ponekad je ljudska intervencija neophodna. Trebalo bi da obavestite administratore slanjem poruke kojim se sredstvima organizacija koristi (instant poruke, e-mail, ili bilo koja metoda.)

Udaljeni objekat
Treća promena podržava okvir kao udaljeni objekat sa opcionim aktiviranjem / deaktiviranjem da se očuvaju resursi.

Inovacija udaljenog metoda dolazi u mnogim oblicima:
        Basic
        Custom Socket Factory
        IIOP
        Portable Object Adapter
        Jini
        Inter Process Communication

Vaša okolina se može sastojati od oblaka sa odvojenim procesorima na više različitih lokacija. Izrada fleksibilnog okvira ima smisla.

Bezbednost
Četvrta promena dodaje sigurnost.

Java ™ bezbednosna tehnologija je deo SE / ME platformi, ona zahteva prednji završetak servera sa bezbednosnim odeljenjima za fleksibilnost.

Administracione funkcije
Peta promena dodaje administracione funkcije.

Evidentiranje je dosadno i uglavnom beskorisno, dok nešto ne pođe naopako.

Statistike su osnova za analizu učinka i podešavanja.

Moramo obezbediti priključke na unutrašnje strukture, tako da korisnici mogu da prate i kontrolišu funkcionalnost. To nije od koristi ako niko ne zna šta to radi. Kada ljudi shvate šta to radi, verovatno će želeti da ga promene.

Pisanje Fork-Join okvira koji je jednostavan za upotrebu i efikasan za lokalne pozive je teško. Činiti isto za pristup mreži je veliki poduhvat.

Koliko vremena će biti potrebno da se izgradi takav server?

Oko 5-6 sekundi. Samo dovoljno dugo da otpakuje jedan fajl.

Srećom, postoje i opšte namene, Fork-Join okviri podržavaju gore navedene osobine za svakodnevne, multi-core Java ™ aplikacije u SE, ME i Android ™ i danas su dostupne. A pošto okvir može da radi kao RMI Server (standardni / activni, IIOP i POA) je na raspolaganju za Java ™ EE aplikacije

Tymeac for the Java™ SE / ME / Android™ platforme su projekti održavanog open source softvera
i tamo možete preuzeti najnovija izdanja.
. SourceForge.net

Zaključak

Korišćenje Fork-Join okvira napravljenog za računarske-intenzivne zajednice možda neće dobro raditi za svakodnevne aplikacije.

Obim Java™ multi-core aplikacija trebalo bi da raspodeli posao u svoje funkcionalne komponente sa profesionalnim kvalitetnim okvirom koji je jednostavan za korišćenje, efikasan, i open source.

 


Published (Last edited): 19-06-2013 , source: http://www.coopsoft.com/ar/ForkJoinArticle.html