Colección de Problemas (2014)

Ejercicio Catalán
Universidad Universidad Politécnica de Cataluña (UPC)
Grado Ingeniería de Sistemas de Telecomunicación - 2º curso
Asignatura Aplicacions i Serveis Telemàtics
Año del apunte 2014
Páginas 19
Fecha de subida 13/11/2014
Descargas 3
Subido por

Vista previa del texto

Part 1 Mecanismes d’espera activa 1. Es vol implementar un m`etode rwlock.enter(int mode) per solucionar el problema Lectors/Escriptors amb espera activa. rwlock (read/write lock) encapsula un sencer que val 0 si la taula esta lliure, -1 si esta sent accedida per un escriptor o el nombre de lectors si esta sent accedida per un conjunt de lectors. L’argument mode ´es 1 si s’accedeix per llegir i -1 si s’accedeix per escriure. Es disposa de les operacions ENTERZC/EXITZC per protegir amb espera activa l’acc´es a Zones Cr´ıtiques. Realitzar la codificaci´ o d’aquest m`etode.
2. Si es disposa d’una operaci´ o at´omica n.atomic dec() que decrementa el valor d’un comptador i retorna el resultat decrementat. Si s’inicialitza el comptador a 1, n = 1, com es pot resoldre el problema d’Exclusi´o M´ utua.
3. Es vol implementar la construci´o await(exp_bool){ codi; } (construcci´ o espera a que) que bloqueja el proc´es fins que exp bool sigui certa i llavors executa codi. Donar una possible codificaci´o d’aquesta construcci´ o.
4. Dos productors, amb comportament id`entic, emeten en seq¨ u`encia els n´ umeros 1 i 2 amb el codi no at` omic ...println(...); buffer.put(i); i acaben.
Dos consumidors llegeixen dos dels n´ umeros cadascun amb el codi no at` omic ...println(...+buffer.get()); 1 2 PART 1. MECANISMES D’ESPERA ACTIVA i acaben.
put i get s´ on operacions d’un monitor buffer. Quins dels seg¨ uents entrella¸cats s´ on correctes?: Entrella¸ cat 1: Consumidor(2) Consumidor(1) Consumidor(1) Consumidor(2) obt´ e obt´ e obt´ e obt´ e 1 2 1 2 Entrella¸ cat 2: Consumidor(1) Consumidor(2) Consumidor(1) Consumidor(2) obt´ e obt´ e obt´ e obt´ e 1 1 2 2 Entrella¸ cat 3: Consumidor(2) Consumidor(1) Consumidor(2) Consumidor(1) obt´ e obt´ e obt´ e obt´ e 2 1 1 2 5. Algorisme de Peterson. Es vol encapsular l’algorisme de Peterson en una classe Mutex amb m`etodes enter() i exit().
Es demana: (a) Els camps de dades de la classe Mutex.
(b) La realitzaci´ o del m`etode enter() suposant que es fa servir una classe MyThread que t´e un camp id sencer que l’identifica.
6. Es disposa d’una classe Counter amb els m`etodes • void dec() que decrementa at`omicament un sencer i no retorna cap valor.
• int intValue() que retorna at`omicament el valor del sencer.
• void setValue(int) que modifica el valor del sencer segons el par` ametre.
Se suposa que el sencer pot guardar qualsevol valor sense desbordament.
Es proposen dues solucions: Soluci´ o 1: // Init Counter n = new Counter(1); ...
3 // Enter do { n.dec(); } while (n.intValue() != 0) ; ...
// Exit n.setValue(1); Soluci´ o 2: // Init Counter n = new Counter(0); ...
// Enter do { n.dec(); } while (n.intValue() != -1) ; ...
// Exit n.setValue(0); Les solucions proposades resolen el problema d’Exclusi´o M´ utua ? 7. Es disposa d’una classe Counter amb els m`etodes • int dec() que decrementa at`omicament un sencer i retorna el valor antic.
• void setValue(int) que modifica el valor del sencer segons el par` ametre..
Se suposa que el sencer pot guardar qualsevol valor sense desbordament.
Utilitzant la classe Counter resoldre el problema d’Exclusi´o M´ utua.
8. Es disposa d’una classe Counter amb els m`etodes • int dec() que decrementa at`omicament un sencer i retorna el valor antic.
• int inc() que incrementa at`omicament un sencer i retorna el valor antic.
• void setValue(int) que modifica el valor del sencer segons el par` ametre..
Se suposa que el sencer pot guardar qualsevol valor sense desbordament.
Es proposen 3 solucions al problema Lectors/Escriptors, on la taula pot ser accedida per un nombre arbitrari de Lectors o b´e per un u ´nic Escriptor.
Soluci´ o 1: // StartRead while (n.inc() == -1) ; ...
// EndRead // StartWrite while (n.dec() != 0) ; ...
// EndWrite 4 PART 1. MECANISMES D’ESPERA ACTIVA n.dec() ; n.setValue(0); Soluci´ o 2: // StartRead while (n.inc() == -1) ; ...
// EndRead n.setValue(0); // StartWrite while (n.dec() != 0) ; ...
// EndWrite n.inc(); Soluci´ o 3: // StartRead while (n.inc() == -1) n.dec(); ...
// EndRead n.dec() ; // StartWrite while (n.dec() != 0) n.inc(); ...
// EndWrite n.inc(); Les solucions proposades resolen el problema Lectors/Escriptors ? 9. One Lane Bridge. Per un pont poden circular cotxes, que es modelen com a threads, en un sentit o en l’altre per`o no en ambd´os sentits a la vegada. Per aix` o es demana dissenyar una classe Bridge amb els m`etodes void enter(boolean way) i void exit().
Un cotxe quan vol accedir al pont fa una crida al m`etode enter(boolean way), passant com a par`ametre la seva direcci´o. Si el pont est`a ocupat per cotxes que circulen en direcci´o contr`aria, aquest s’haur`a d’aturar. Un cop un cotxe abandona el pont crida el m`etode exit().
Part 2 Monitors 1. Sigui un proc´es productor i n processos consumidors que comparteixen un buffer de capacitat b. Cada element depositat pel productor ha de ser agafat pels n consumidors, per`o aquests poden agafar els elements en qualsevol moment. Un lector pot anar avan¸cat com a molt b posicions respecte la resta de lectors.
En resoldre el sistema fent servir monitors, la classe Monitor Buffer queda definida com: Monitor_Buffer : int dades[b]; //vector de dades int llegits[b]; //no de lectures sobre la posici´ o //del vector dades[] boolean hi_ha[b]; //posici´ o del vector de //dades[] lliure/ocupada int punter_lec[n]; //punter de lectura de cada lector int punter_esc = 0; //punter d’escriptura de l’escriptor int num_esc = 0; //nombre d’escriptures total int num_lec[n] = 0; //nombre de lectures //total de cada lector condition pot_llegir; condition pot_escriure; //inicialitzaci´ o corresponent; int get(int id) { . . . }; void put( int elem) { . . . }; (a) Donar una possible soluci´o del m`etode int get(int id).
(b) Donar una possible soluci´o del m`etode void put(int elem).
2. (One lane bridge) Per un pont poden circular cotxes, que es modelen com a threads, en un sentit o en l’altre per`o no en ambd´os sentits a la vegada. Per aix` o es dissenya un monitor bridge amb sem`antica Signal and Continue que no te en compte cap criteri de justicia a l’hora d’accedir al pont. El monitor bridge t´e definits dos m`etodes: enter() i exit() i els atributs: nombre cotxes: cotxes que estan passant pel pont en cada moment 5 6 PART 2. MONITORS sentit actual: sentit en que estan passant els cotxes en cada moment (a) Implementar el m`etode enter() en pseudo-codi.
(b) Implementar el m`etode exit() en pseudo-codi.
3. Es vol implementar el firmware d’un commutador ATM amb un canal de sortida sobre el qual es transmet informaci´o de diferents connexions amb prioritats. Aquest firmware v´e definit per diferents processos productors (connexions) i 1 proc´es consumidor (canal de sortida) que comparteixen un buffer de transmissi´o de capacitat b. Els processos productors tenen definida una prioritat d’acc´es sobre el buffer de 0 a n-1, essent n-1 la prioritat m` axima. Aix`o vol dir que mentre hi hagi espai al buffer poden accedir-hi lliurement, per`o quan el buffer s’ha omplert, els processos productors seran aturats i posteriorment despertats segons l’ordre de prioritat.
En resoldre el sistema fent servir monitors amb variables de condici´o amb sem` antica Signal and Continue, la classe Buffer queda definida com: import Monitor.*; public class Buffer extends Monitor { private CircularQueue q; //variable de condici´ o per aturar el consumidor: private Condition empty; //variables de condici´ o segons prioritat pels product.: private Condition full[]; //nombre de productors esperant d’una prioritat: private int producer[]; //prioritat m´ es alta en qualsevol moment: private int priority; public Buffer(int cp){ q = new CircularQueue(cp); empty = create_cond(); producer = new int[n]; full = new Condition[n]; for(int i=0; i<n+1; i++){ full[i] = create_cond(); producer[i] = 0; } priority = -1; } public Object get() {...} 7 public void put(Object element, int my_priority) {...} } (a) Donar una possible implementaci´o del m`etode Object get( ).
(b) Donar una possible implementaci´o del m`etode void put(Object element, int my priority).
4. Sigui un proc´es escriptor i n processos lectors que comparteixen un buffer de capacitat b. Cada element dipositat pel escriptor ha de ser agafat pels n lectors, per` o aquests poden agafar els elements en qualsevol moment.
Un lector pot anar avan¸cat com a molt b posicions respecte la resta de lectors degut a la capacitat limitada del buffer.
En resoldre el sistema fent servir monitors amb variables de condici´o amb sem` antica Signal and Continue, la classe Monitor Buffer queda definida com: public class Monitor_Buffer extends Monitor { protected int N; protected int B; // vector de dades: protected int[] dades; // lectures disponibles de cada lector: protected int[] lect_disp; // punter d’escriptura (de 0 a B-1): protected int punter_escr; protected Condition pot_escriure; protected Condition pot_llegir; public Monitor_Buffer(int n, int b) { N = n; B = b; dades = new int[B]; lect_disp = new int[N]; pot_escriure = create_cond(); pot_llegir = create_cond(); } public void put(int elem) {...} // cid ´ es l’identificador del lector(de 0 a N-1): public int get(int cid) {...} } (a) Donar una possible implementaci´o del m`etode void put(int elem).
(b) Donar una possible implementaci´o del m`etode int get(int cid).
Nota: l’expressi´ o ((punter escr + B - lect disp[cid]) % B) equival a (punter escr - lect disp[cid]) amb aritm`etica m`odul B.
8 PART 2. MONITORS 5. En un sistema hi ha dos tipus de processos concurrents NoPrior i Prior que accedeixen en exclusi´o m´ utua a un recurs com´ u. Els processos Prior tenen prioritat sobre els NoPrior, ´es a dir, quan arriba un proc´es Prior passa davant de tots els NoPrior que puguin estar esperant per accedir al recurs.
Es vol resoldre aquest sistema fent servir monitors de Java. D’aquesta forma es defineix una classe amb els seg¨ uents atributs i les seves inicialitzacions que gestiona l’acc´es a trav´es dels m`etodes demanar recurs( ) i alliberar recurs( ): //N´ umero de processos Prior en espera: int cuaP=0; //N´ umero de processos NoPrior en espera: int cuaNoP=0; //Indica si algun proc´ es est` a accedint al recurs: boolean ocupat=false; (a) Implementar el m`etode demanar recurs. El par`ametre tipus representa el tipus de proc´es (0=NoPrior i 1=Prior).
(b) Implementar el m`etode alliberar recurs.
6. Considerem el problema Productor/Consumidor amb monitors i ordre de servei FIFO on les operacions son servides en l’ordre d’arribada dels threads (suposant que la cua del bloc synchronized t´e servei FIFO).
Es demana: (a) La programaci´o amb mecanismes de sincronitzaci´o JAVA del constructor de la clase bufferFIFO.
(b) La programaci´o amb mecanismes de sincronitzaci´o Java de l’operaci´o put 7. Considerem el problema Lectors/Escriptors de manera que es garanteix u ´nicament l’acc´es concurrent de tots els Lectors i l’acc´es exclusiu d’un Escriptor.
Es demana: (a) La programaci´o de les operacions synchronized void StartRead() i synchronized void StartWrite().
(b) La programaci´o de la operaci´o synchronized void EndRead().
(c) La programaci´o de la operaci´o synchronized void EndWrite().
8. Molts sistemes aconsegueixen implementar l’exclusi´o m´ utua definida en els paquets de sem`afors i monitors programats amb llenguatges d’alt nivell gr` acies a l’´ us d’una instrucci´o de llenguatge m`aquina disponible en molts microprocessadors anomenada TestAndSet. Es tracta d’una instrucci´ o m` aquina (per tant at`omica) de manipulaci´o d’un bole`a, si es consulta la primera vegada canvia internament de valor (test and set) retornant el valor inicial; per consultes posteriors retorna el valor actual 9 sense modificar-lo. Amb una instrucci´o m`aquina diferent es pot tornar a resetejar el bole` a.
Sigui la classe TestAndSet de JAVA que emula l’instrucci´o de L.M. TestAndSet definida com: public class TestAndSet { private boolean flag; public TestAndSet() {flag = false;} ... // m` etodes test_and_set() i reset() } Realitzar una implementaci´ o del m`etode test and set() 9. Es vol crear un monitor que permeti intercanviar valors a parelles de processos. El monitor nom´es t´e una operaci´o: intercanvi(int valor).
Despr`es de que dos processos hagin invocat intercanvi(int valor), el monitor intercanvia els valors dels arguments i els retorna als processos.
Suposeu que a la cua de monitor mai hi han m´es de 2 processos esperant.
Implementeu el monitor.
10. Es vol dissenyar un programa que “justifiqui” text, provinent d’un proc´es P1 que genera objectes de tipus String de longitud variable. El funcionament del programa ´es el seg¨ uent: el proc´es P1 genera un objecte de tipus String i l’introdueix en un monitor de tipus Buffer String a caracter de capacitat m´es gran que la longitud de qualsevol objecte String generat.
P1 introdueix l’objecte String de cop, per`o el Buffer String a caracter emmagatzema internament els car`acters per separat. El proc´es P2 extreu els car` acters un a un, i els introdueix en un altre monitor de tipus Buffer caracter a linia. El proc´es P3 ´es el que extreu objectes del monitor Buffer caracter a linia. Els objectes que el proc´es proc´es P3 extreu s´ on de tipus String i tenen longitud igual a la capacitat del monitor Buffer caracter a linia.
Es proposar la realitzaci´ o de: (a) El codi del m`etode put de la classe Buffer String a caracter.
(b) El codi del m`etode get de la classe Buffer String a caracter.
(c) El codi del m`etode put de la classe Buffer caracter a linia.
(d) El codi del m`etode get de la classe Buffer caracter a linia.
11. Un compte d’estalvis ´es compartit entre diferents processos. Cada proc´es pot treure o dipositar diners. El balan¸c del compte mai pot ser negatiu.
Construir un monitor Signal and Continue que resolgui aquest problema amb les operacions dipositar(quantitat) i extreure(quantitat).
Es proposa la implementaci´ o de: 10 PART 2. MONITORS (a) El codi de l’operaci´o dipositar.
(b) El codi de l’operaci´o extreure.
12. Si es modifica el monitor del problema 11 per garantir que les operacions son resoltes per ordre d’arribada, ´es a dir, si hi ha 1000 i arriba un proc´es que vol treure 2000 i a continuaci´o arriba un altre proc´es que vol treure 500, aquest u ´ltim proc´es s’haur`a d’esperar a que el que en vol 2000 les pugui treure.
S’hauria de realitzar (a) El codi de l’operaci´o dipositar.
(b) El codi de l’operaci´o extreure.
13. Suposem que el seg¨ uent monitor s’utilitza per controlar l’acc´es de varis processos a un recurs compartit.
class ControlAcces extends Monitor { protected boolean lliure = true; protected Condition torn; // Aquirir recurs public void adquirir(){ mon_enter(); if (!lliure) { torn.wait(); } lliure = false; mon_exit(); } // Alliberar recurs public void alliberar(){ mon_enter(); lliure = true; torn.signal(); mon_exit(); } } Amb quina disciplina funciona correctament aquest monitor? 14. Es vol simular un mecanisme de pas de missatges ass´ıncron en JAVA.
A tal efecte es construeix la seg¨ uent classe Canal. El m`etode rebre ´es bloquejant en el cas en que no existeixin missatges en el canal.
public class Canal { private int num_miss; private Vector missatges; 11 public Canal(){ num_miss = 0; missatges = new Vector(); } ... enviar (Object o) { ...
} ... rebre() { ...
} } Es demana implementar el codi dels m`etodes enviar i rebre, de manera que les respostes siguin compatibles entre si.
15. ProductorsABCs: Una aplicaci´o disposa de tres tipus de processos. Els processos A produeixen a’s, els processos B produeixen b’s i els processos C necessiten (consumeixen) una a i una b per a produir ab’s. Es vol resoldre el problema ProductorsABCs, sense exclusi´o m´ utua i amb possibilitat de m´es d’una producci´ o pendent, utilitzant monitors. El codi dels processos ´es: Proc´ es A: //produir a monitor.pa(); Proc´ es B: //produir a monitor.pb(); Proc´ es C: monitor.pab(); //produir ab Implementar el codi del monitor.
16. En un sistema hi ha dos tipus de processos concurrents NoPrior i Prior que accedeixen en exclusi´ o m´ utua a un recurs com´ u. Els processos Prior tenen prioritat sobre els NoPrior, ´es a dir, quan arriba un proc´es Prior passa davant de tots els NoPrior que puguin estar esperant per accedir al recurs.
Es vol resoldre aquest sistema fent servir monitors de Java. D’aquesta forma es defineix una classe amb els seg¨ uents atributs i les seves inicialitzacions que gestiona l’acc´es a trav´es dels m`etodes demanar recurs() i alliberar recurs(): //N´ umero de processos Prior en espera: int cuaP=0; 12 PART 2. MONITORS //N´ umero de processos NoPrior en espera: int cuaNoP=0; //Indica si algun proc´ es est` a accedint al recurs: boolean ocupat=false; (a) Implementar el m`etode alliberar recurs.
(b) Si el par` ametre tipus representa el tipus de proc´es (0=NoPrior i 1=Prior), implementar el m`etode demanar recurs(int tipus).
Part 3 Pas de missatges 1. Un thread de classe B vol veure incrementat un comptador en N unitats.
Per aix` o s’ajuda de N threads de classe A que s’executen concurrentment i incrementen cadascun d’ells el comptador en una unitat. Aquest comptador pren el valor inicial zero. Els threads no comparteixen mem`oria i es comuniquen a trav´es d’un parell de sockets connectats. Els threads A comparteixen un socket d’un extrem anomenat socket A i el thread B usa el socket de l’altre extrem anomenat socket B.
(a) Implementar el codi dels threads A (b) Implementar el codi dels threads B 2. N threads de classe A s’executen concurrentment amb un thread de classe B. Es vol que el thread B s’executi quan els N threads A hagin acabat. Per aix` o es disposa d’un parell de sockets connectats on un d’ells, socket A, ´es compartit pels threads A, el thread B fa servir socket B.
Es demana (a) La codificaci´ o del m`etode run() de la classe A.
(b) La codificaci´ o del m`etode run() de la classe B.
3. Es vol programar el problema d’exclusi´o m´ utua distribu¨ıt amb control d’acc´es centralitzat en un ` arbitre (monitor actiu) concurrent. out ´es de tipus PrintWriter i in de tipus BufferedReader.
Es proposa realitzar (a) El protocol de comunicaci´o del Client.
(b) El fragment de codi dels threads de l’`arbitre que dialoguen amb el Client.
4. Symetric Socket: Es vol fer servir un model sim`etric de connexions punt a punt amb un thread a cada extrem. Un thread defineix un socket amb la funci´ o Socket connect(String conn name) que retorna un socket de la connexi´ o de nom conn name connectat amb el socket de l’altre extrem.
Fins que no es connecta, la funci´o bloqueja el thread. L`ogicament, un 13 14 PART 3. PAS DE MISSATGES extrem haura de ser el socket actiu (Socket) i l’altre s’obtindr`a a partir del socket passiu (ServerSocket).
Per a la implementaci´o del model es fa servir un thread servidor amb nom SERVERNAME i port SERVERPORT p´ ublics que mant´e un conjunt de parells (conn name, (peername, peerport)) formats per el nom de la connexi´o i el nom i port del host de l’altre extrem (peer). Aquest conjunt ´es una taula de hash.
Si l’extrem ´es el socket passiu, solicita al sistema la obtenci´o d’un port no usat. Aix´ o es fa passant 0 al constructor ServerSocket i obtenint el port assignat amb getLocalPort. Tamb´e obt´e el nom de host amb getHostName.
Es demana: (a) La programaci´o de connect.
in i out s´ on els streams d’Input i Output de sock. str ´es un String local de connect.
(b) La programaci´o del Servidor que dialoga amb connect.
in i out s´ on els streams d’Input i Output de sock. ht ´es la taula de hash. Peer ´es la classe formada per el parell (peername, peerport).
5. Un monitor actiu utilitza el mecanisme de pas de missatges per emular el funcionament dels monitors convencionals de mem`oria compartida. En aquest cas el monitor es converteix en un proc´es m´es de forma que l’entrada a monitor, sortida de monitor i l’equivalent al wait() i notify() s´on el resultat de l’intercanvi de missatges entre la resta de processos i el proc´es monitor.
Partint del sup` osit que contem amb els m`etodes send(dada) i dada = receive() a on el m`etode send() no ´es bloquejant, per`o el m`etode receive() s´ı que ho ´es: (a) Programar la part del client i la del monitor actiu de l’emulaci´o d’entrada a monitor amb un monitor actiu monothread.
(b) Programar la part del client i la del monitor actiu del wait() amb un monitor actiu monothread.
6. Es vol realitzar un servidor que faci les funcions d’un buffer de missatges amb capacitat ilimitada, al qual els clients interaccionen amb pas de missatges. El codi principal del servidor ´es el seg¨ uent: public class Server { static Semaphore mutex; static Shared shared; public static void main(String[] args) { int port = Integer.parseInt(args[0]); mutex = new Semaphore(1); shared = new Shared(); 15 try { ServerSocket srv_sock = new ServerSocket(port); while (true) { Socket conn_sock = srv_sock.accept(); new Service(conn_sock).start(); } } catch (IOException e) { System.out.println(e); } } } class Service extends Thread { BufferedReader input; PrintWriter output; Service(Socket sock) throws IOException { input = new BufferedReader( new InputStreamReader( sock.getInputStream() ) ); output=new PrintWriter(sock.getOutputStream(),true); } public void run() { try { while (true) { String msg = input.readLine(); if (msg == null) break; if (msg.equals("put")) { msg = input.readLine(); Server.mutex.P(); Server.shared.process_put(this,msg); Server.mutex.V(); } else if (msg.equals("get")) { Server.mutex.P(); Server.shared.process_get(this); Server.mutex.V(); } else if (msg.equals("size")) { Server.mutex.P(); Server.shared.process_size(this); Server.mutex.V(); } } } catch (IOException e) { System.out.println(e); } } 16 PART 3. PAS DE MISSATGES } Es proposa realitzar: (a) El codi de la classe Shared.
(b) El fragment de codi corresponent a l’operaci´o de posar un missatge en el buffer. Respecte al codi dels possibles clients, suposarem que input i output s´ on el BufferedReader i el PrintWriter corresponents al socket connectat amb el servidor.
(c) El fragment de codi corresponent a l’operaci´o de treure un missatge del buffer 7. One lane bridge: Per un pont poden circular cotxes, modelats com a threads, en un o altre sentit, per`o no en ambdos sentits a la vegada. Es programa una soluci´o amb pas de missatges pura amb clients remots, proxies o agents en l’extrem servidor i monitor actiu que fa el control d’acc´es.
Els clients realitzen l’operaci´o enter(id, turn) per solicitar l’entrada del cotxe id al pont en sentit turn i exit() per sortir del pont. El codi del monitor actiu usa una variable l de tipus ArrayList, operacions read str, read int i write char per llegir un String, un int i escriure un char a trav´es d’un Socket respectivament i respon al seg¨ uent esquema: while (true) { if (cond) { A } else { B } if (str.equals("enter")) { C } else { D } } Us proposa d’implementar: (a) El codi if (cond) A.
(b) El codi B.
(c) El codi C.
(d) El codi D.
8. En un entorn distribu¨ıt hi ha N processos que es comuniquen per pas de missatges. Cada proc´es te un identificador diferent, ID (amb valors de 0 a N-1), i un n´ umero enter meu val (amb un valor positiu qualsevol). Es vol construir una aplicaci´o per aconseguir que tots els processos puguin con`eixer el valor (meu val) m´es gran. Per fer-ho es considera un anell (virtual), on el proc´es ID rep el m`axim provisional, calculat per el proc´es ID-1, compara aquest valor amb el seu valor, calcula el m`axim dels dos 17 valors i l’envia al proc´es seg¨ uent, ID+1 mod N. Despr´es d’una volta, el primer proc´es (ID=0) ja rep el m`axim. Finalment es fa una segona volta on aquest m` axim es passa a tots els processos.
L’esquelet del codi de cadascun dels processos ´es el seg¨ uent: public class proces extends Thread{ int ID; //Identificador del proc´ es int meu_val; //Valor emmagatzemat per el proc´ es int val_max; //Valor m` axim provisional int valor_maxim; //Valor m` axim de tots els processos int N; //N´ umero de processos //El proc´ es rep l’identificador i el seu valor.
public proces(int ID, int meu_val, int N){ this.ID=ID; this.meu_val=meu_val; this.N=N; } private int llegir_enter(Socket s){ ....
//Retorna un enter llegit de s } private void escriure_enter(Socket s, int en){ ....
//escriu un enter a s } private int esperar_valor(){ ...
} private int comparar_valor( int val){ ...
} private void enviar_valor(int val_max){ ...
} private void enviar(int val_max){ ...
} public void run(){ int val; //primera volta val_max=meu_val; 18 PART 3. PAS DE MISSATGES val=esperar_valor(); val_max=comparar_valor(val); enviar_valor(val_max); //segona_volta valor_maxim=esperar_valor(); enviar_valor(valor_maxim); } } Es demana la realitzaci´o de: (a) El codi del m`etode esperar valor().
(b) El codi del m`etode comparar valor(int val).
(c) El codi del m`etode enviar valor(int val max).
(d) El codi del m`etode enviar(int val).
Part 4 Aspectes de concurr` encia 1. Siguin les classes definides com: class Fil extends Thread { String missatge; Fil(String m){ missatge = m; } public void run(){ while(true){ System.out.println(missatge); } } } public class ExecutaFils { public static void main(String args[]){ Fil filA = new Fil("A"); Fil filB = new Fil("B"); filA.run(); filB.start(); } } Quina ´es la sortida del programa? 19 ...