// Semaphore.java package semaphore; public class Semaphore { int resources = 1; // Constructors Semaphore() {} Semaphore(int i) { resources = i; } synchronized void down() {while.. wait();..} synchronized void up() {.. notify();} } Skitse af semafor-klasse

synchronized void down() { while (resources <= 0) { try {wait();} catch.. } resources = resources - 1; } synchronized void up() { resources = resources + 1; notify(); } down() og up()

Semafor brugt til at beskytte kritisk sektion i database-record Agent Semaphore Agent Record sem.down(); rec.X = rec.X +1; sem.up(); X er globalt data

Et objekts lås og mængder af ventende tråde public class Semaphore { synchronized void down() { while.. wait();.. } synchronized void up() {.. notify(); } lås s-mængde w-mængde sem (Semaphore-objekt) Låst hvis et objekt er i gang med at udføre en metode, som er synchronized De tråde, som er blokeret fordi de venter på at udføre en metode, som er synchronized De tråde, som er blokeret fordi de har udført wait() i Semaphore-objektet (og som ikke er blevet resume-de endnu)

Hvem sættes i kø hvor ? "Hvem ?" og "hvor ?" spørgsmål til synkronisering. Hvem suspenderes ? Det gør tråde, og specifikt den tråd som vil udføre en synchronized metode i et låst objekt, eller som udfører et kald af wait(). Hvor anbringes de suspenderede tråde ? De tilknyttes det objekt, der indeholder metoden med synchonized / wait(). Rækkevidden af notify() og notifyAll() er de suspenderede tråde, som er knyttet til det objekt, der indeholder metoden med notify()/notifyAll()

public class Record { integer X; synchronized void incr() { while.. wait();.. X = X + 1; notify(); } lås s-mængde w-mængde rec (Record-objekt) Alternativ til brug af semafor

Semafor-operationer: down og up skal være atomiske // Forenklet implementation i C af semaforer // Semaforen er repræsenteret ved et heltal. down(int *sem) { if (*sem=0) {SLEEP UNTIL WAKEUP}; *sem = *sem - 1; } up(int *sem){ *sem = *sem + 1; {WAKEUP ONE SLEEPING PROCESS}; } ? sleep *Sem-- *sem++ wakeup

Metoder/faciliteter til interproces-kommunikation Fra OS-kurset: Filer Semaforer Besked-køer Pipes Andre: Signaler Delt hukommelse

Besked-køer ….. msgsnd(..);.. msgrcv(..);.. Afsender skal angive - adresse = ? - længde af besked - prioritet - flag som styrer opførsel i specialtilfælde

Sockets vs. besked-køer Ligheder: formål: interproces-kommunikation implementation: kerne-understøttet (hvis andre sprog, f.eks. Java, bruger faciliteterne, er det via C) global navngivning af kommunikations-mediet strømme hvis indhold forbruges ved læsning Forskelle: sockets kan også forbinde processer på forskellige maskiner sockets kan forbinde maskiner med forskellige operativsystemer en besked-kø kan have flere sendere og/eller modtagere beskeder er afgrænsede beskeder har prioritet

Boss/workers brug af besked-køer … Boss Worker

Boss/workers brug af (TCP-baserede) sockets accept(..): Bruges til automatisk at generere ny socket-forbindelse for hver ny request fra klient. Oprettelse af forbindelse mellem worker/klient lettes Prioritet/type behøves ikke til at identificere afsender eller modtager Da sockets ikke grupperer det overførte data i beskeder, skal modtageren parse input-strømmen blot for at finde ud af hvorfra og hvortil en "besked" går.

Formål med Farleys multitrådede webserver/problemsolver (eks ) Klient/browser Server Solver Håndtering af multiple klienter

Server Thread RunnableSolver Solver-objekt parameteroverføres til Thread-objekt ProblemSet Farleys multitrådede server - de vigtigste klasser Client Socket- forbindelse class RunnableSolver { void solve() {..} public void run() { solve(); }.. }

Kombination af RMI og multitrådning: Design Server: 1 tråd modtager nye forespørgsler 1 tråd per klient behandler klientens forespørgsel (nu via fjernt solver-objekt) varetager socket-kommunikation med klient Solver på fjern maskine: 1 solver-objekt for hvert klient-tråd (helst) Solver tråd Server

Thread Solver ProxySolver Server som kan tilgå 1 fjernt solver-objekt ProblemSet 0..n

class RunnableProxyServer Version 1: ét fjernt solver-objekt class RunnableProxySolver implements Runnable, Solver { RMIProblemSet currProblem; OutputStream clientOut; InputStream clientIn; RunnableProxySolver(..) {..}; RMISolver s; void solve() { currProblem =..; s = (RMISolver) Naming.lookup(..); s.solve(currProblem,..);.. } public void run() { solve(); }.. } Alle bruger det samme solver-objekt Alle har sit eget problem-objekt Til/fra klient

class RMISolverImpl class RMISolverImpl implements RMISolver { RMIProblemSet currProblem; void setProblem(RMIProblemSet s) { currProblem = s; } boolean solve() { currProblem.setSolution(Math.sqrt(currProblem.getValue())); } boolean solve(RMIProblemSet s,..) {.. }.. } // forenklet i forhold til Farleys program synchronized ? Bruger solve/2 den globale setProblem ?

Samtidig brug af et fjernt objekt Flere tråde kan samtidig få udført metode-kald i et objekt uanset om det er fjernt eller på samme maskine hvis metoden bruger delte, globale variable, skal den synkroniseres hvis metoden ikke bruger delte, globale variable, svarer metoden til et funktionskald og bruger ikke objektets tilstand

Party Filosof Gaffel take_forks(..) Filosof = separat tråd Samtidig brug af metode i objekt i samme proces

Faser i elektronisk handels- transaktion Jf. SET Spec., Book 1, afsnit Kortindehaver "browser" Kortindehaver beslutter sig for køb. 4. Kortindehaver vælger betaling (kreditkort via SET). 5. Kortindehaver sender ordre til e-købmand (afsnit 4.4). 6. E-købmand tjekker hos kortindehavers bank (4.5). 7. E-købmand sender ordrebekræftelse til kortindehaver (4.4). 8. Levering/ydelse af vare/tjenesteydelse. 9. Pengeoverførsel til e-købmand. (4.6) Krav til websider Krav til SET- implementation

Krav til SET-godkendt e-handels-server Langvarige transaktioner som involverer 3 parter: kortindehaver købmanden selv SET gateway Beregningstunge opgaver: offentlig nøgle kryptering/dekryptering af korte strenge symmetrisk nøgle kryptering af lange strenge Datatunge opgaver - database med: varekatalog kundeoplysninger (omend ikke kreditkortsnumre..) Forhåbentlig mange transaktioner !