Asynkrona meddelanden och trådpooler

Litteratur

Allt i samma tråd (4.1.2)

    public void server() {
        for (;;) {
            Request r = waitForRequestFromBrowser();
            handler.handleRequest(r);
        }
    }

}
Webservern ligger i en evig loop där den väntar på anrop från webläsare. När det kommer ett anrop skickas det vidare till ett objekt av klassen RequestHandler som avkodar begäran från browsern, läser in den efterfrågade HTML-filen och skickar tillbaks den över nätet. Det asynkrona meddelandet är anropet handler.handleRequest(). Sändaren är ett objekt av klassen WebServer och mottagaren är objektet handler.

Ovanstående konstruktion av webservern är urusel eftersom den inte kan svara på ett anrop innan den är helt klar med föregående anrop. Svarstiden kommer att bli på tok för lång, en användare som surfar till en sajt vilken hanteras av ovanstående webserver kommer förmodligen att anta att sajten är nere eftersom det tar så lång tid att få svar. Dessutom kommer sannolikt webserverns inbuffert att bli full av alla väntande anrop, vilket leder till att nya anrop tappas. Detta är ett praktexempel på när det lönar sig att göra ett program flertrådat.

En tråd per meddelande (4.1.3)

    public void server() {
        for (;;) {
            final Request r = waitForRequestFromBrowser();
            new Thread(new Runnable() {
                public void run() {
                    new RequestHandler().handleRequest(r);
                }
            }).start();
        }
    }

}
Nu kommer en ny tråd att skapas och startas på varje varv i for-loopen. Allt den nya tråden gör är att exekvera det asynkrona meddelandet handleRequest(). Varje gång ett meddelande skickas skapas alltså en ny tråd som kör meddelandet och sedan dör. Detta är en mycket bättre lösning än den föregående, men den är knappast den bästa. Problemet är dels att det tar ganska lång tid att skapa en ny tråd och starta den. Det innebär att svarstiden blir något längre än om tråden som skulle exekvera meddelandet redan fanns. Dessutom kan denna strategi leda till att för många trådar skapas om det kommer många anrop i snabb följd. Detta kan till exempel orsaka att webservern krashar på grund av att minnet tar slut.

Trådpool (4.1.4)

    public void server() {
        for (;;) {
            final Request r = waitForRequestFromBrowser();
            workers.execute(new Runnable() {
                public void run() {
                    new RequestHandler.handleRequest(r);
                }
            });
        }
    }

}

class WorkerPool {
    protected final Channel workQueue = new Channel();

    public void execute(Runnable r) {
        workQueue.put(r);
    }

    public WorkerPool(int nWorkers) {
        for(int i=0; i<nWorkers; i++) {
            activateWorker();
        }
    }

    protected void activateWorker() {
        Runnable runLoop = new Runnable() {
            public void run() {
                for (;;) {
                    Runnable r = (Runnable)workQueue.take();
                    r.run();
                }
            }
        };
        new Thread(runLoop).start();
    }

}
Klassen WorkPool innehåller ett antal trådar som utför de meddelanden som skickas till dem via metoden execute(). Klassen Channel kan vara en vanlig buffer i stil med den BufferArray vi tidigare använt.

Det finns ett flertal frågeställningar att fundera kring när en trådpool ska implementeras. Här är några av dem:

• Identitet Trådarna i en trådpool är anonyma, dvs det är omöjligt att få tag i den tråd som utför en viss uppgift. Det är också omöjligt att behandla trådarna olika på något sätt. Om inte detta är OK är det förmodligen olämpligt att använda en trådpool över huvud taget.
• Farligt med beroenden Det kan vara farligt med beroenden mellan olika uppgifter i kön. Det kan till exempel vara olämpligt om en exekverande uppgift är beroende av något som ska utföras av en uppgift som fortfarande ligger kvar i kön.
• Kön kan bli full Om uppgifter läggs in i kön fortare än de kan utföras av trådarna kommer kön snart att vara full, vilket innebär att antingen den äldsta uppgiften eller den nya som inte får plats kommer att tappas bort och aldrig bli utförd. Om detta inte är lämpligt kan någon av följande åtgärder vidtas: Skapa nya trådar, låt kön växa, inför någon sätt för trådpoolen att meddela de som använder den att inte lägga in fler uppgifter eller låt metoden som tar emot uppgifter blockera uppgiftslämnaren (lämpligtvis med wait()) tills det finns en ledig plats i kön.
• När skapas och avslutas trådar?

I klassen WorkerPool ovan skapas alla trådar direkt i konstruktorn när en ny instans skapas, sedan finns de kvar "för alltid". En alternativ lösning är att skapa en ny tråd först när den behövs, dvs när det börjar finnas väntande uppdrag i kön. Det leder i och för sig till ökad svarstid de gånger en uppgift får vänta på en ny tråd. En kompromiss mellan dessa två tillvägagångssätt är att ett fåtal trådar skapas när trådpoolen instansieras. Det kan kanske också vara lämpligt att begränsa det tillåtna antalet samtidiga trådar för att exekveringen inte ska bli slö på grund av till exempel minnesbrist. Ytterligare en fråga är om trådar ska avslutas när de inte behövts under en viss tid. Detta kan frigöra resurser som trådarna håller men kan även göra trådpoolen långsammare eftersom en del ytterligare logik tillkommer.
• Cancellation

Ska det gå att avsluta en uppgift utan att avsluta tråden som utför den? Vad ska hända om den tråd som lade in uppgiften i kön dör?