coordinamento di Andrea de Prisco Dalle stelle allo stallo · coordinamento di Andrea de Prisco...

4
MULTIT ASKING coordinamento di Andrea de Prisco Dalle stelle allo stallo di Luciano Macera Figura I- Ipotesi di sistema composto da una CPu. una memoria e tre risorse condivise UI. U2. U3. In questa puntata di Multitasking, parleremo del problema dello stallo di due o più processi. Situazione in cui si ha praticamente un blocco del sistema non a causa di errore di programmazione dei singoli processi, ma solo per la concorrenza di questi e per il fatto che il sistema sul quale ci muoviamo concede con troppa ((leggerezza» l'uso esclusivo di risorse condivise Problema di feeling Lo scorso mese abbiamo visto come proteggerci da incauti utilizzi delle risor- se condivise regolando l'accesso a que- ste tramite funzioni di sistema come la «Lock-UnLock» o i meno rudimentali semafori. Non ci siamo però, volutamente, po- sti il problema di come proteggerci dallo stallo ossia da quelle situazioni in cui più processi non possono proseguire per- ché in attesa di risorse in quel momen- to utilizzate da altri processi che atten- dono a loro volta altre risorse utilizzate da noi. È chiaro che se il processo «A» assu- me il controllo esclusivo della risorsa «a» e tenta di accaparrarsi anche la risorsa «b» attualmente in uso presso il processo «B» che a sua volta cerca di guadagnare la risorsa «a», i due proces- s[ rimarranno bloccati (in stallo) per sempre. A meno di non prendere i soliti, necessari, provvedimenti. Facciamo subito un primo esempio: immaginiamo di dover accedere in ma- niera esclusiva ad una struttura dati condivisa sulla quale effettuare opera- zioni. Fatto questo procediamo all'acqui- sizione di una seconda struttura dati per aggiornarla con i nuovi valori della prima per poi terminare ancora le operazioni su quest'ultima prima di rilasciarla com- pletamente. Potrebbe essere l'esempio della lista posti e lista attesa di un qualsiasi volo aereo: chiusa l'accettazione dei preno- tati è necessario accedere alla lista dei posti per conteggiare quelli ancora libe- ri, accedere alla lista d'attesa per prele- vare un pari numero di viaggiatori «spe- ranzosi», e accedere nuovamente alla lista posti per aggiornare l'elenco dei viaggiatori. Utilizzando le «P» e «V» viste lo scor- so mese, il processo potrebbe avere una struttura di questo tipo: P(Sem1) Utilizzo struttura P(Sem2) Aggiornamento struttura 2 V(Sem2) Utilizzo struttura V(Sem1) Un'altra procedura, differente dalla prima potrebbe avere la necessità di accedere alle due strutture dati condivi- se in ordine inverso: P(Sem2) Utilizzo struttura 2 P(Sem1) Aggiornamento struttura V(Sem1) Utilizzo struttura 2 V(Sem2) Cosa succede se le due procedure appena mostrate sono eseguite con- temporaneamente ad esempio da due terminali diversi? Molto probabilmente si ha uno stallo in quanto il primo processo acquisisce l'uso esclusivo della struttura 1 e non la rilascia fino a quando non ha eseguito tutte le sue operazioni. Contemporaneamente potrebbe fare lo stesso la seconda procedura, acqui- sendo l'uso esclusivo della struttura 2 prima che lo faccia anche il primo pro- cesso. In pratica potremmo facilmente trovarci nella situazione in cui il proces- so 1 ha acquisito la struttura 1, il pro- cesso 2 ha acquisito la struttura 2, il processo 1 attende la liberazione della 292 MCmicrocomputer n. 106 - aprile 1991

Transcript of coordinamento di Andrea de Prisco Dalle stelle allo stallo · coordinamento di Andrea de Prisco...

Page 1: coordinamento di Andrea de Prisco Dalle stelle allo stallo · coordinamento di Andrea de Prisco Dalle stelle allo stallo di Luciano Macera Figura I-Ipotesi di sistema composto da

MULTIT ASKINGcoordinamento di Andrea de Prisco

Dalle stelle allo stallodi Luciano Macera

Figura I - Ipotesi di sistema composto da una CPu. una memoria e tre risorse condivise UI. U2. U3.

In questa puntata diMultitasking, parleremo delproblema dello stallo di due opiù processi. Situazione in cuisi ha praticamente un bloccodel sistema non a causa dierrore di programmazione deisingoli processi, ma solo perla concorrenza di questi e peril fatto che il sistema sul qualeci muoviamo concede controppa ((leggerezza» l'usoesclusivo di risorse condivise

Problema di feeling

Lo scorso mese abbiamo visto comeproteggerci da incauti utilizzi delle risor-se condivise regolando l'accesso a que-ste tramite funzioni di sistema come la«Lock-UnLock» o i meno rudimentalisemafori.

Non ci siamo però, volutamente, po-sti il problema di come proteggerci dallostallo ossia da quelle situazioni in cui piùprocessi non possono proseguire per-ché in attesa di risorse in quel momen-to utilizzate da altri processi che atten-dono a loro volta altre risorse utilizzateda noi.

È chiaro che se il processo «A» assu-me il controllo esclusivo della risorsa«a» e tenta di accaparrarsi anche larisorsa «b» attualmente in uso presso ilprocesso «B» che a sua volta cerca diguadagnare la risorsa «a», i due proces-s[ rimarranno bloccati (in stallo) persempre. A meno di non prendere isoliti, necessari, provvedimenti.

Facciamo subito un primo esempio:immaginiamo di dover accedere in ma-niera esclusiva ad una struttura daticondivisa sulla quale effettuare opera-zioni. Fatto questo procediamo all'acqui-sizione di una seconda struttura dati peraggiornarla con i nuovi valori della primaper poi terminare ancora le operazionisu quest'ultima prima di rilasciarla com-pletamente.

Potrebbe essere l'esempio della listaposti e lista attesa di un qualsiasi voloaereo: chiusa l'accettazione dei preno-tati è necessario accedere alla lista deiposti per conteggiare quelli ancora libe-ri, accedere alla lista d'attesa per prele-vare un pari numero di viaggiatori «spe-ranzosi», e accedere nuovamente allalista posti per aggiornare l'elenco deiviaggiatori.

Utilizzando le «P» e «V» viste lo scor-so mese, il processo potrebbe avereuna struttura di questo tipo:

P(Sem1)Utilizzo strutturaP(Sem2)Aggiornamento struttura 2V(Sem2)Utilizzo strutturaV(Sem1)

Un'altra procedura, differente dallaprima potrebbe avere la necessità diaccedere alle due strutture dati condivi-se in ordine inverso:

P(Sem2)Utilizzo struttura 2P(Sem1)Aggiornamento strutturaV(Sem1)Utilizzo struttura 2V(Sem2)

Cosa succede se le due procedureappena mostrate sono eseguite con-temporaneamente ad esempio da dueterminali diversi?

Molto probabilmente si ha uno stalloin quanto il primo processo acquisiscel'uso esclusivo della struttura 1 e non larilascia fino a quando non ha eseguitotutte le sue operazioni.

Contemporaneamente potrebbe farelo stesso la seconda procedura, acqui-sendo l'uso esclusivo della struttura 2prima che lo faccia anche il primo pro-cesso. In pratica potremmo facilmentetrovarci nella situazione in cui il proces-so 1 ha acquisito la struttura 1, il pro-cesso 2 ha acquisito la struttura 2, ilprocesso 1 attende la liberazione della

292 MCmicrocomputer n. 106 - aprile 1991

Page 2: coordinamento di Andrea de Prisco Dalle stelle allo stallo · coordinamento di Andrea de Prisco Dalle stelle allo stallo di Luciano Macera Figura I-Ipotesi di sistema composto da

MULTITASKING

Figura 2 - Tabelle e grati delle prenotazioni risorse condivise.

quello del secondo:

8(b) B

G8

(d) BG

8(I)

risorsa condivisa viene generato all'in-terno del sistema il grafo delle prenota-zioni ed esplorato per stabilire se esisteo meno la possibilità di stalla.

La tabella delle prenotazioni è forma-ta da una riga per ogni risorsa condivisae contiene i seguenti campi:1) stato della risorsa2) processo utilizzatore3) lista prenotazioni.

Il primo campo è generalmente im-piegato per indicare lo stato della risor-sa in questione. Il secondo indica ilprocesso che, in quel momento, stautilizzando in modo esclusivo la risorsa.Il terzo campo contiene la lista dei pro-cessi che hanno prenotato la risorsa mache ancora non ne hanno chiesto l'usoesclusivo. A partire dalla tabella delleprenotazioni è generato il grafo delleprenotazioni come mostrato nei treesempi di figura 2.

Nel primo dei tre esempi l'unità Ul èattualmente utilizzata dal processo Pl eha una prenotazione da parte di P3 eP2, l'unità U2 è utilizzata da P2, l'unitàU3 è utilizzata da P3 e ha una solaprenotazione da parte di P2. Nel grafocorrispondente (figura 2b) gli archiuscenti dai nodi «processo» indicanol'utilizzo in esclusiva da parte di questi,gli archi uscenti dai nodi «unità» indica-no le dipendenze dovute alle prenota-zioni. Così U3 (sempre in figura 2b) è

stato Proc Prenl Pren2 Pren3

Ul BUSY P1 P3

U2 BUSY P3 P2

U3 BUSY P2

stato Proc Pren1 Pren2 Pren3

Ul BUSY P1 P3

U2 BUSY P2 P1

U3 BUSY P3 P2

stato Proc Pren1 Pren2 Pren3

U1 BUSY P1 P3 P2

U2 BUSY P2

U3 BUSY P3 P2

(e)

A questo punto il sistema rifiuterà laP(Sem2, Seml) del secondo processose verrà eseguita dopo la complementa-re richiesta del processo 1, evitando inquesto modo lo stalla. Ma come fa ilsistema per stabilire che una certa se-quenza di prenotazioni può indurre unostalla?

L'algoritmo esiste, ma per descriverlonel più semplice dei modi ci avvarremodi un grafo.

In pratica il sistema mantiene unatabella delle prenotazioni che si modifi-ca man mano che vengono eseguite levarie P e V sui semafori. Prima di con-cedere o meno l'uso esclusivo di una

(a)

(c)

P(Sem 1, Sem2)Utilizzo strutturaP(Sem2)Aggiornamento struttura 2V(Sem2)Utilizzo strutturaV(Sem1)

P(Sem2, Sem1)Utilizzo struttura 2P(Sem1)Aggiornamento struttura 1V(Sem1)Utilizzo struttura 2V(Sem2)

Una prima soluzioneUn primo metodo drastico per risolve-

re il problema è quello di vedere le varierisorse cui siamo interessati nel corsodella nostra elaborazione come un'unicarisorsa indivisibile. In altre parole avre-mo un solo semaforo che controlla l'ac-cesso simultaneo a tutte le risorse (ingioco) contemporaneamente. In praticaogni processo che accede ad una qual-siasi risorsa condivisa blocca l'accessoa tutte le risorse disponibili e dunque,banalmente, il problema è risolto utiliz-zando erroneamente la forza.

Erroneamente proprio perché siavrebbe un costoso degrado delle pre-stazioni globali a causa del fatto chenon è giusto bloccare tutto il bloccabilesolo perché un singolo processo deveaccedere ad una singola risorsa. E in piùsarebbe come fare un vergognoso pas-so indietro rispetto alla gestione risorse«a semafori» che ha proprio come van-taggio principale il fatto di suddividere lerisorse condivise in classi distinte eproprio per questo singolarmente arbi-trabili.

Ciò che bisogna fare è prevenire ipossibili stalli: agire prima che sia trop-po tardi con metodi non cruenti (esclu-dendo, cioè, la possibilità di uccidere iprocessi coinvolti in uno stalla).

Grafi e prenotazioniUn metodo per prevenire gli stalli c'è

e consiste nell'istituire, oltre alla mutuaesclusione implementata attraverso se-mafori, un meccanismo di prenotazionedelle risorse.

In pratica ogni processo quando entrain una sezione critica che a sua voltacontiene altre sezioni critiche chiedel'uso esclusivo della prima e in più siprenota per quelle che, eventualmente,utilizzerà al suo interno.

Il sistema concederà in questo modol'uso esclusivo della prima sezione criti-ca solo se le prenotazioni indicate nongenerano la possibilità di stalla con glialtri processi (che a loro volta hannofornito le loro prenotazioni).

Nell'esempio sopra visto, la prima Psul Seml diventerà una P su Seml conprenotazione Sem2: in pratica si chiedeche venga dato l'uso esclusivo dellarisorsa controllata da Sem 1 e si avvisa ilsistema che prima di rilasciare tale risor-sa potrebbe essere utilizzata anche larisorsa controllata da Sem2.

Il codice del primo processo diventagrosso modo così:

struttura 2 (in mano al processo 2 che,di certo, non la rilascia) e il processo 2attende la struttura 1. Attesa infinita ...

MCmicrocomputer n. 106 - aprile 1991 293

Page 3: coordinamento di Andrea de Prisco Dalle stelle allo stallo · coordinamento di Andrea de Prisco Dalle stelle allo stallo di Luciano Macera Figura I-Ipotesi di sistema composto da

Figura 3 - Tabella prenotazioni e relativo grafo per sei processi che si contendono sei unità. Nella secondadelle due ipotesi si ha uno stalla.

MULTITASKING

utilizzata in maniera esclusiva da P3 edavendo quest'ultimo una prenotazioneanche per U1 (P3 compare infatti anchenella lista prenotazioni di questa unità) ècon questa collegata da un arco unità-unità

L'assenza di stallo è graficamenterappresentata dall'assenza di cicli di di-pendenza tra le unità: non esiste infattiun percorso che partendo dall'unità UXattraverso le frecce dirette torni nuova-mente sull'unità di partenza.

Diverso è il caso della tabella di figura2c e relativo grafo di figura 2d. Lì ilpercorso circolare esiste, infatti parten-do da un qualsiasi nodo unità seguendole frecce si torna allo stesso nodo dipartenza: stallo immediato.

Del resto dando uno sguardo più at-tento alla relativa tabella possiamo de-durre lo stallo anche senza bisogno digrafo. L'unità U1 è utilizzata da Pl'l'unità U2 è utilizzata da P2; l'unità U3 èutilizzata da P3. Inoltre P3 ha una preno-tazione per U1, P2 per U3 e Pl per U1.P1 «mollerà» Ul dopo aver utilizzatoanche U2 che è utilizzata da P2 che lalascerà dopo aver utilizzato U3. Questa,a sua volta, è utilizzata da P3 che lalascerà dopo aver usato anche U 1 che èutilizzata attualmente da Pl. Classicogatto che si morde la coda ..

Costruiamo un grafoCome esempio finale di quest'articolo

proviamo a giocare con sei processi chesi contendono l'assegnazione esclusivadi altrettante risorse condivise. Possia-mo immaginare che al sistema operati-vo arrivino le seguenti sei richieste daaltrettanti processi:

P1:. P(Sem 1, Sem2, Sem3, Sem5)P2:: P(Sem2)P3' P(Sem3, Sem5)P4:: P(Sem4, Sem21P5:: P(Sem5)P6:: P(Sem6, Sem1, Sem4)

Come negli esempi precedenti il se-maforo «SemX» controlla l'unità UX enelle P con più parametri il primo identi-fica il semaforo sul quale si richiedel'accesso. I rimanenti parametri indica-no le prenotazioni su altrettante risorsecondivise. Ad occhio, sapreste giudicarese la sequenza di P sopra indicata met-te i processi (non necessariamente tut-ti) in stato di stallo?

No, non c'è stallo: possono esseresoddisfatte tutte le P. Vediamo perché:ci aiuteremo con un grafo, mostrato infigura 3b. La costruzione è assai sempli-ce. Si tracciano tanti nodi quante sonole unità condivise e da ognuno di questitante frecce dirette verso i nodi segna-

294

stato Proc Prenl Pren2 Pren3

Ul BUSY Pl P6

U2 BUSY P2 Pl P4

U3 BUSY P3 Pl

U4 BUSY P4 P6

U5 BUSY P5 Pl P3

U6 BUSY P6

(a)

stato Proc Prenl Pren2 Pren3Ul BUSY Pl P6

U2 BUSY P2 Pl P4

U3 BUSY P3 PlU4 BUSY P4 P6

U5 BUSY P5 Pl P3

U6 BUSY P6 P5

(c)

lati nelle liste di prenotazione. Così daquanto evidenziato dalla prima delle seiP da U 1 tracceremo tre frecce versoU2, U3, U5. Con la seconda P, nonessendoci prenotazioni non aggiungere-mo alcuna freccia. Con la terza P tracce-remo semplicemente un arco da U3 aU5 e così via fino alla sesta P ottenendoil grafo mostrato in figùra 3b. Comefacilmente visibile «ad occhio» non esi-ste un percorso circolare che partendoda uno qualsiasi dei nodi riporti al nododi partenza: non c'è infatti pericolo distallo.

Certo la cosa cambia se poco dopoP5 esegue una V(Sem5) (liberando U5)e prima che altri processi blocchino larisorsa esegue un bel P(Sem5, Sem6).La tabella prenotazioni è mostrata infigura 3c, il nuovo grafo in figura 3d.Qui lo stallo c'è in quanto esiste unpercorso circolare che partendo da U1,U5 o U6 porta allo stesso nodo dipartenza: il sistema non deve permet-tere questo: P5 verrà sospeso comese avesse trovato la sezione critica oc-cupata da un altro processo mentresarà concessa la medesima sezione cri-tica ad esempio a Pl o P3 che avendo-la già precedentemente prenotata nonaggiungono nuovi archi al grafo e quin-di probabilità di «introdurre» cicli equindi stalli.

(b)

(d)

Dal punto di vista del computerCerto un conto è prendere carta e pen-

na e disegnare un bel grafo, ben altro è lavisione dal punto di vista del computerche ha schemi di funzionamento diversidalla nostra visione-intuizione. Un grafopuò essere memorizzato sotto forma dilista multipla in cui i nodi sono gli elemen-ti della lista e gli archi i puntatori traquesti. E la visita di un grafo non è certoun problema irrisolvibile, specialmentequando si hanno a disposizione linguaggidi programmazione ricorsivi. In altre paro-le il grafo viene costruito e aggiornato inmemoria ad ogni chiamata P contenenteprenotazioni. L'aggiornamento in questomodo è semplicissimo: basta riportarenei vari campi i puntatori agli elementiindicati nella lista di prenotazione. Per lavisita i problemi non sono poi così tanti. Siparte infatti dal nodo che abbiamo in quelmomento aggiornato (relativo alla unitàche si intende utilizzare, indicata nel pri-mo parametro della P) e da quello siscorre il grafo come fosse un albero. Lavisita ha esito positivo solo se terminasenza mai ripassare per il nodo in parten-za. Da notare che non è possibile entrarein cicli in cui non è compreso l'ultimonodo aggiornato in quanto ciò indichereb-be la preesistenza di cicli che avremmodovuto scartare precedentemente. r;;rs

MCmicrocomputer n. 106 - aprile 1991

Page 4: coordinamento di Andrea de Prisco Dalle stelle allo stallo · coordinamento di Andrea de Prisco Dalle stelle allo stallo di Luciano Macera Figura I-Ipotesi di sistema composto da

o o' E.CI.S. 'COMPUTER ..VENDITA Al MINUTO E PER CORRISPONDENZA

UNICA AD UNIRE PRODOTII DI ALTA QUALITA' A PREZZI CONTENUTISSIMIVIA CASTRO DEI VOLSCI 40/42 UJCOlLi AlBANI- 00179 ROMA - TEL. 06/7810593-7803856

CONTATTATECI GARANTIAMO QUALITA' CORTESIA COMPETENZATUTTI I NOSTRI PRODOTTI SI INTENDONO GARANTITI 12 MESI - PREZZI IVA ESCLUSA

ORARIO 9.30 - 13.00/16.30 - 19.30 GIOVEDI CHIUSO - SABATO APERTOPOSSIBILITA' ANCHE DI VENDITA RATEIZZATA (SOLO PER ROMA)

MS DOS COMPUTERAT 16 MHZ 1MB, FLOPPY 1,44MB, VGA 800x6oo, TASTIERA 101, OESK TOP, PARALLELA, SERIALE, HO 40MB, JOYSTICK 1.200.000386 SX 20 MHZ, 1MB, FLOPPY 1,44MB, VGA 800x600, TASTIERA 101, OESK TOP, PARALLELA, SERIALE, HO 40MB 1.800.00038635 MHZ, 1MB, FLOPPY 1,44MB, VGA 8oox600, TASTIERA 101, OESK TOP, PARALLELA, SERIALE, HO 40MB 2.400.000386 54MHZ, 64 CASH, 2MB, FLOPPY 1,44MB, VGA 8OOx600,OESK TOP, TASTIERA 101, PARALLELA SERIALE, HO 80MB 3.400.000486117MHZ, 4MB, FLOPPY 1,44MB, VGA 1024, OESK TOP, TASTIERA 101, PARALLELA, SERIALE, HO40MB 5.800.000PORTATILE NOTEBOOK 286 VGA, HO 20, FO 1.44MB, KG. 2.6 2.800.000PORTATILE NOTEBOOK 386 FX, HO 20MB, FO 1.44MB, FO EXT 1.2 MB, VGA, KG. 2.6 3.850.000PORTATILE VERYOATA 286, 21 MHZ, FO 1.44MB, HO 40MB, VGA 3.150.000PORTATILE VERYOATA 386/20 FO 1.44MB, HO 40MB, VGA 4.350.000

ATIENZIONE l SUI NOSTRI PREZZI NON VI SONO SGRADEVOLI SORPRESE: SI INTENDONO PER MACCHINE COMPLETE DI TUTIO

CONTATTATECI PER QUALSIASI CONFIGURAZIONE PERSONALIZZATA, SAPREMO ACCONTENTARVI !!

DRIVE 720K 100.000DRIVE 1.2MB 129.000FLOPPY1,44MB 129.000CGNHERCULES 60.000VGA 800 x 600 130.000VGA 1024 x 768 + ZOOM 210.000VGA 1M+ZOOM 294.000TASTIERA101 TASTI 71.000PARALLELA+ 2 SERIALI 50.000CONTROLLER AT MFM 120.000CONTROLLERAT BUS 40.000SCANNER+ OCR 299.000FAX META 20 MEMORIE 850.000COPROCESSORI MATEM. IMM. DISPONIBILIA PREZZI ECCEZIONALI.

(WINJ1E®[gIMlIrD©:

PIASTRAXT 12MHZPIASTRAAT 16MHZPIASTRAAT 21MHZPIASTRA386 SX 20MHZPIASTRA386 28MHZPIASTRAmadre 386/33 CACHEPIASTRA486/117 MHZHARDISK SEAGATE124-20HARDISK SEAGATE 157-40 AT BUSHARDISK QUANTUM 40MBHARDISK QUANTUM 80MBHARDISK MAXTOR 80MB, 17M1S 1"HARDCARD 40MB per Amstrad e Amiga

CDROM INT. + CONTROLLERMONITOR TIL VERDEMONITOR DUAL 12"MONITOR DUAL 14" B/IN

110.000199.000240.000550.000

1.000.0001.850.0004.500,000

280.000390.000550.000700.000699.000S46.000630.000126.000150.000190.000

MONITOR EGA AMBRAMONITOR VGA BIANCOCOLORE VGA 1024x768 0,28COLORE VGA 800x600 0,31COLORE VGA 640x480 0.39COLORE MULTYSINCHMUL TISYNCH MITSUBISHIMULTISYNCH NEC 11IDMOUSE da LireMODEM INTERNO 1200MODEM INTERNO 2400MODEM ESTERNO1200MODEM ESTERNO2400TAVOLETIA GRAFICACABINET DESKTOPCABINET MONITOWERDRIVE 360K

218.000210.000590.000550.000510.000700.000924.000

1.020.00050.00099.000

227.000168.000252.000400.000142.000243.000100.000 80287/12 260.000

CENTRO ASSISTENZA E RIPARAZIONI IN 24 ORE DI OGNI DIFETIO.VOLETE RICEVERE IMMEDIATAMENTE IL NOSTRO DETTAGLIATISSIMO LISTINO?

COLLEGATEVI DOPO LE 20.00 CON LA NOSTRA BBS. NE RIMARRETE ENTUSIASTI: TEL 06/7803856

LINEA GVP AMIGADRIVE ESTERNO 160.000HD 80MB 11M/S + CTRL 1.000.000ESPANSIONE 2000 8MB 490.000ACCELERAT. 16MHZ 950.000ACCELER. 28MHZ A3001 3.500.000CONTR. HD PLUS8 400.000HD 40MB 11M/S. + CTRL 880.000HD 40MB + CTRL + 2MB RAM

1.486.000HD 500 15M1S 40 MB 1.000.boo

COMMODORE

AMICA 500 588.000AMICA 2000 1.260.000COMMODORE 64 NEW 220.000MONITOR PHILlPS DD 33110378.000DRIVE PERCBM 64 205.000DRIVE EST.AMICA 139.000DRIVE INT. A2000 120.000ESPANSIONE AMICA 500 84.000MONITOR CBM 10845 NEW 400.000SCANNER AMICA 336.000MOUSE AMICA 50.000CENLOCK A 2301 340.000CENLOCK AMICA' 470.000DICIVIDEO AMICA 110.000DICIAUDIO AMICA 110.000ANTIFLICKERINC 800.000VIDEON 3.0 462.000HD 2000 2090 714.000HD A590 500 714.000MIDI AMICA 67.000

FlOPPY DISK5 1/4 DSDD 4625 1/4 HD MITO 1.6803 1/2 DSDD 7563 1/2 SSDD SONY 1.09231/2 DSDD MITSUBISHI 1.2613 1/2 HD 1.680

STAMPANTI

IMMEDIATAMENTE DISPONIBILEA PREZZO IMBATTIBILEQUALSIASI MODELLODELLE SEGUENTI CASE:

[E[p$(Q) N$1T~IR

«:~1TU7l[ENN[E«:

ATARI1040ATARI 1040 STEATARI MECA 1ATARI MECA 2ATARI MECA 4DRIVE EST.ATARIHD ATARI 30MBMONITOR ATARI MONOMONITOR COL. X ATARI

700.000720.000740.000990.000

1.250.000185.000900.000200.000420.000

PREZZIIVA ESCLUSA • GARANZIA 12 MESI • RICHIEDERE IL NOSTRO CATALOGO CON 350 ARTICOLI