Informatyka Nr 10; Organ Komitetu Naukowo-Technicznego NOT ds. Informatyki - Digital Library of the Silesian University of Technology

C ena 250 zl

Dr Leslie Lamport o specyfikowaniu systemów współbieżnych

M a s z y n y i a l g o r y t m y r ó w n o l e g ł e E I w r o 800

. . - fi :

im o r im 10 ¹⁹⁸⁸

N r 10

M ie s ię c z n ik R o k X X III

P a ź d z ie rn ik 1988

O r g a n K o m it e t u

N a u k o w o - T e c h n ic z n e g o N O T ds. In f o r m a t y k i

K O L E G IU M R E D A K C Y JN E : M g r J a ro s ła w D E M IN E T . d r inż. W a c ta w IS Z K O W S K I.

m g r Teresa J A B Ł O Ń S K A (s e k re ta rz re d a k c ji).

W ła d y s ła w KLEPAC Z (re d a k to r n a c z e ln y ), d r in ż. M a re k M A C H U R A , d r inż. W ik to r R ZE C ZK O W S K I, m g r inż. Ja n RYŻKO.

m g r H anna W Ł O D A R S K A , d r inż. Ja nu sz ZA L E W S K I (za stę p ca re d a k to ra n a c z e ln e g o ).

PR ZE W O D N IC Z Ą C Y R AD Y P R O G R A M O W E J:

P ro f. d r hab.

J u liu s z Lech K U L IK O W S K I

M a te r ia łó w n ie z a m ó w io n y c h re d a kcja n ie z w ra c a

R ed a kcja : 01 -517 W a rs z a w a , ul. M ic k ie w ic z a 18 m. 17, te l. 39-1 4 -3 4

RSW „P R A S A -K S IĄ Ż K A -R U C H ' P R A SO W E Z A K Ł A D Y G R AFIC Z N E u l. D w o rc o w a 13, 8 5-9 5 0 BY D G O S Z C Z Zam . 3 530/88. E -4

O b j. 4,0 a rk. d ru k . N a kła d 9050 egz.

ISSN 0542-9951. IN D E K S 36124

Cena e g z e m p la rza 200 zł P re n u m e ra ta ro czn a 2400 zł

S WYDAWNICTWO

i i

?i/i o

5

1 s i

SIGMA

^£ni

00-950 Warszawa skrytka pocztowa ¡004

ul. Biała 4

W N U M E R Z E :

Uproszczone specyfikow anie system ów współbieżnych (1)

Leslie Lam port

M aszyny i algorytm y równoległe (1)

Maciej M. Systo

V H D L - A d a języków opisu i projektow ania sprzętu

H enryk Gizdoń, A d a m P aw lak, W łodzim ierz Wrona

System m ikro kom puterow y E lw ro 800 (1)

Wojciech Cellary, Jerzy Kręglewski, R u ta M aćkowiak

Efek tyw n o ść system u dBase I I I

Michał Kabsch

Turbo C. M odele pamięci, adresowanie, wskazania adresowe

Jan Bielecki

Stero w an ie przepływ ow e (2). Im plem entacja modelu

R om an P odraża

Przegląd technik grafiki kom puterowej (2)

Wojciech M okrzycki

R E C E N Z J E

W prowadzenie do grafiki kom puterowej I. O. Angella

T E R M IN O L O G IA

Term inologia system ów operacyjnych (2)

12

15

17

25

24

29

W N A JB L IŻ S Z Y C H N U M E R A C H :

* H e n r y k G iz d o ń , A d a m P a w l a k i W ło d z im ie r z W r o n a p o d a j ą p ie r w s z ą c z ę ść sz c z e g ó ło w e j c h a r a k t e r y s t y k i j ę z y k a o p is u s p r z ę t u V H D L , z a w i e r a j ą c ą r o z w i ą z a n i a w e r s j i 7.2 te g o j ę z y k a .

0 P i o t r F u g le w ic z i R o m a n T o p c z y ń s k i o p i s u j ą p r o g r a m D A G G E R , b ę d ą c y p r z e d s t a w ic ie ­ le m n o w e j g e n e r a c j i o p r o g r a m o w a n ia d la k o m p u t e r ó w r o d z in y M e ra 60/660 i s y s te m ó w o p e r a c y j n y c h R T -1 1 , R T -6 0 i M T R -6 0 .

0 A d a m T u c h o ls k i c h a r a k t e r y z u j e z b ió r p r o c e d u r N E T B IO S z a p e w n ia ją c y s p r z ę to w o n ie z a le ż n e s p r z ę ż e n ie m ię d z y a d a p t e r e m s ie c i k o m p u t e r o w e j a s y s te m e m o p e r a c y jn y m D O S.

0 T a d e u s z C z a c h ó r s k i i in . p r e z e n t u j ą p a k i e t p r o g r a m o w y A M O K d o m o d e lo w a n ia i o c e n y d z i a ł a n i a s y s te m ó w k o m p u te r o w y c h .

0 A g n ie s z k a M y k o w ie c k a i A n n a O s ta s z e w s k a z a j m u j ą s ię p r o b l e m a t y k ą k o m u n i k a c j i z k o m p u t e r e m w j ę z y k u n a t u r a l n y m .

0 J a n B ie le c k i k o n t y n u u j e s e r i ę a r t y k u ł ó w o j ę z y k u T u r b o C, o m a w i a j ą c ty m r a z e m p r z e r w a n i a , s y g n a ł y i p o w r o ty .

0 D o r o ta I n k i e l m a n o m a w ia ś r o d o w is k o p r o g r a m o w e A d y .

LESLIE LAMPORT

D igital Equipm ent Corporation System s Research Center Palo Alto, stan K alifornia USA

A r t y k u ł je s t d o k o n a n ym za zgodą fir m y D E C tłu m acz en ie m a po rtu: L . L a m p o rt, A S im p le A p p ro a ch to S p e c ify in g C o n çu r­

e n t System s. T e c h n ic a l R e p o rt 15, D E C S y s te m s R e s e a rch C en ter, P a lo A lto (C A ), D ecem b e r 1986

Uproszczone specyfikowanie systemów współbieżnych (1 )

W artyku le przedstawiono metodę aksjomatu przejść (ang.

transition axiom method

), w której w łaściw ości bezpieczeństwa system u współbieżnego można w yspecyfikow ać za pomocą pro­

gramów, a właściw ości żywotności specyfikuje się przez asercje w prostej logice temporalnej. Metodę opisano za pomocą k ilku prostych przykładów, a jej podstawy logiczne wyjaśniono niefor­

m alnie badając, co oznacza zrealizowanie specyfikacji. Zagad­

nienia językow e i inne szczegóły, praktycznie w większości pominięto.

W P R O W A D Z E N I E

W ciągu ostatnich k ilk u lat rozwinąłem podejście do specyfi- kow ania system ów współbieżnych, które obecnie nazywam metodą aksjom atu przejść. Podstaw o w y formalizm tej metody opisano w [1, 7], lecz szczegóły form alne przesłaniają jej istotne pojęcia. Poniżej spróbuję w yjaśnić te pojęcia bez szczegółowego om awiania ic h podstaw teoretycznych.

System y współbieżne nie są łatw e do specyfikowania. N aw et prosty system może być bardzo subtelny i często trudno jest znaleźć odpowiednie abstrakcje, które uczynią go zrozumiałym.

Specyfikow anie złożonego system u jest ciekaw ym zadaniem inżynierskim . Złożone stru k tu ry można zrozumieć tylko wtedy, gdy składają się z prostych części, tak w ięc metoda specyfikow a­

nia złożonych system ów musi mieć proste podstawy pojęciowe.

Spróbuję w ykazać, że metoda aksjomatu przejść ma takie podstawy. Jed n akże nie będę zajm ował się zagadnieniami inży­

nierskim i związanym i ze specyfikow aniem rzeczywistych syste­

mów. Zilustruję natomiast poszczególne pojęcia kilkom a ła tw y ­ m i przykładam i, których nie można traktow ać poważnie jako rzeczywistych specyfikacji.

Czy proponuję język specyfikacyjny ?

Nie. Metoda aksjomatu przejść daje pojęciowe i logiczne podstawy do tworzenia specyfikacji form alnych, nie jest nato­

miast językiem specyfikacyjnym . Metoda określa, co powinna w yrażać specyfikacja, a język określa szczegółowo,

ja k

to ma być wyrażone.

Co

rozumiem przez specyfikację fo rm a ln ą ?

Stw ierdziłem , że bardzo korzystne jest rozważanie specyfika­

cji jak o um ow y (ang.

contract)

między użytkow nikiem systemu a jego w ykonaw cą. U m o w a powinna m ówić użytkow nikow i wszystko, co powinien on wiedzieć, aby używ ać system u i mó­

w ić realizatorowi (ang.

implementer)

wszystko, co powinien on wiedzieć, aby ten system zrealizować. Z reguły, jeśli um owa zostanie uzgodniona, to użytkow nik i realizator nie mają potrze­

by dalszego porozum iewania się. T a k i pogląd w yraża

funkcję

specyfikacji, nie stanowi natomiast paradygm atu, ja k należy budować systemy.

P o to, aby specyfikacja była form alna, pytanie „C z y realizacja spełnia specyfikację?” musi być sprowadzalne do pytania „C z y

asercja jest m ożliwa do udowodnienia w pew nym systemie m atem atycznym ?” . A b y w ykazać, że spełnione są w aru n ki um owy, realizator powinien odw oływ ać się do logiki, a nie do zasad praw nych. Nie znaczy to, że realizacji musi towarzyszyć dowód m atem atyczny. Znaczy to natomiast, że w zasadzie, choć niekoniecznie w praktyce, powinno być możliwe dostarczenie dowodu poprawności realizacji. Istnienie form alnych podstaw m etody specyfikacji jest jed yn ym sposobem, ja k i znam, aby zagwarantować, że specyfikacje są jednoznaczne.

Ponadto specyfikowane system y są obiektami fizycznymi, a m atem atyka nie może dowodzić w łaściwości fizycznych. Moż­

na dowodzić jed yn ie właściw ości modelu m atematycznego sys­

temu. To, czy system poprawnie realizuje model, musi pozostać zagadnieniem praw nym , a nie m atem atycznym .

Czym właściwie jest system ?

Przez

system

rozumiem wszystko, co oddziałuje ze swoim otoczeniem w sposób d yskretny (cyfrow y) przez dobrze określo­

ną granicę. System rezerwacji lotniczej jest takim systemem, którego granicę można poprowadzić między używ ającym i go operatorami, stanowiącym i część otoczenia, a term inalam i sta­

now iącym i część systemu. Procedura w Pascalu jest systemem, którego otoczeniem jest pozostała część programu, z którą oddziałuje ona odpowiadając na w yw o łan ia i używ ając zm ien­

nych globalnych. T ak więc, specyfikow any system może być składnikiem innego, większego systemu.

System słoneczny nie jest systemem w tym sensie, ponieważ nie jest systemem dyskretnym i nie ma dobrze określonego pojęcia otoczenia, z którym on oddziałuje.

Rzeczywiście system y m ają wiele istotnych właściwości, od c za su ‘reakcji

(ang.

response time) aż do koloru szaf. Żadna metoda fo rm a ln a nie pozw ala na specyfikow anie w szystkich tych właściwości. Które z nich mogą być specyfikow ane za pomocą metody aksjom atu przejść?

Metoda aksjomatu przejść specyfikuje zachowanie systemu, tzn. ciąg obserw owalnych akcji w yk o n yw an ych przez system podczas oddziaływania z otoczeniem. M ów iąc dokładniej, okreś­

la ona dwie klasy właściw ości dotyczących zachowania systemu:

w łaściwości bezpieczeństwa i żywotności. W łaściw ości bezpie­

czeństwa określają, co system może robić lub 7 równoważnie - czego nie może robić. Częściowa poprawność jest przykładem w łaściwości bezpieczeństwa zapewniającej, że program nie m o­

że generować niepopraw nych odpowiedzi. Właściw ości żyw ot­

ności określają, co system musi robić. Term inalność jest p rz yk ła ­ dem w łaściwości żywotności zapewniającej, że program musi ostatecznie w ygenerow ać odpowiedź. T e dwie klasy w łaściw ości zdefiniowali form alnie A lp e rn i Schneider [2]. W metodzie aksjomatu przejść właściwości bezpieczeństwa i żywotności są specyfikowane oddzielnie.

N iektóre istotne właściw ości dotyczące zachowania nie mogą być specyfikowane metodą aksjomatu przejść. Należą do nich m. in. średni czas reakcji i prawdopodobieństwo aw arii (ang.

probability offailure).

Metodą aksjom atu przejść można zbudo­

w ać form alny model służący do analizy takich w ła śc iw o śc i1), ale nie można ich form alnie specyfikować.

Istnieją również ważne w łaściw ości system ów nie dotyczą­

cych zchowania, ja k np. w ym agania pam ięciowe lub kolor szaf, które n iekiedy należałoby specyfikować. Leżą one jed n ak całko­

w icie poza zakresem tej metody.

Dlaczego właściwości bezpieczeństwa i żywotności specyfi- kuje się oddzielnie?

Poniew aż metoda aksjom atu przejść jest oparta na jed noli­

tym formalizmie, nie ma formalnego rozdziału m iędzy specyfika­

cją właściw ości bezpieczeństwa i żywotności. Jednakże, ja k w ykazu je doświadczenie, do dowodzenia obu rodzajów w łaści­

wości stosuje się różne techniki, dlatego w praktyce wygodnie jest je rozdzielić. Uważarp, że zdolność do dekom ponowania specyfikacji na w łaściw ości bezpieczeństwa i żywotności jest jedną z zalet tej metody. W celu zw eryfikow ania właściw ości żywotności należy dowieść właściw ości bezpieczeństwa, lecz ten dowód można zdekomponować na prostsze lem aty.

Czy tą metodą m ożna specyfikować zachowanie w czasie rzeczyw istym ?

Można specyfikow ać najgorsze przypadki, ponieważ w ym a ­ ganie, aby system reagował w określonym odcinku czasu, można w yrazić jak o w łaściw ości bezpieczeństwa, m ianowicie, że zegar nie może osiągnąć określonej wartości, zanim nie uzyska się odpowiedzi systemu. Śred n i czas reakcji nie może być w yrażony jak o właściw ości bezpieczeństwa lub żywotności.

Metodą aksjom atu

przejść

m ożna zapewnić, że pewne akcje m uszą w ystąpić (żywotność) lub nie mogą w ystąpić (bezpieczeń­

stwo). Czy m ożna również zapewnić, że określona akcja może

u ;y

stąpić?

Nie.

Specyfikacja narzuca ograniczenia kontraktow e na za­

chowanie systemu. Asercja, że system może coś zrobić lub może nie zrobić, nie stanowi ograniczenia i dlatego nie odgrywa żadnej roli jak o część specyfikacji formalnej. W metodach specyfikacji, w których stosuje się takie asercje, służą one za substytuty w łaściwości żywotności. N iektó rym i metodami nie można w y ­ specyfikow ać właściwości, że określony sygnał w ejściow y

m usi

spowodować określoną reakcję, zamiast tego specyfikujei się, że jest możliwe, aby po określonym sygnale w ejściow ym w ystąpiła określona reakcja. Każda specyfikacja, z jak ą się zetknąłem, używ ąjąca takich asercji, była ulepszona przez ich zastąpienie właściw ościam i żywotności, które dokładniej w yrażają niefor­

m alne w ym agania nakładane na system.

N ieprecyzyjne w yrażanie się może spraw ić wrażenie, że specyfikacja zawiera asercję możliwości, podczas gdy w rzeczy­

wistości jej nie zawiera. Przykładow o, często żąda się, aby b yły dopuszczalne straty wiadom ości w lin ii transm isyjnej. Jednakże w specyfikacji nie w ym aga się, aby straty wiadom ości b y ły dopuszczalne, ponieważ w ykluczałob y to realizację, która gw a­

rantuje transm isję bez strat wiadomości. Specyfikacja może w ym agać, aby coś się stało (właściw ość żywotności) lub coś się nie stało (właściw ość bezpieczeństwa) bez względu na straty wiadomości. Stw ierdzenie, że wiadom ości mogą być tracone, może być także kom entarzem do specyfikacji nie będącym jej częścią, w yrażającym fakt, że nie w ym aga się dostarczania wszystkich wiadomości.

Jeśli właściwość bezpieczeństwa zapew nia, ze pewrtar akcja nie może wystąpić, to czy jej negacja zapew nia, że ta akcja jest m ożliw a ?

W system ie logicznym należy odróżnić form ułę logiczną A od asercji i-A, która oznacza, że A jest możliwe do udowodnienia w tej logice. Sam a asercja ł-A nie jest form ułą tej logiki. W logice leżącej u podstaw m etody aksjom atu przejść, jeżeli A reprezen­

tuje właściw ość bezpieczeństwa, to negacja A , tzn. form uła - A, zapewnia, że ta akcja musi w ystąpić. M ożliwość akcji jest

tor. przykład a n aliz y a w a rii zastosow any do specyfikacji [11].

w yrażona przez negację hA, które je s t m etatwierdzeniem , a nie formułą w tej logice (por. [6]).

W Ł A Ś C I W O Ś C I B E Z P I E C Z E Ń S T W A

W pierwszej części przedstawię specyfikację autom atu z w o­

dą sodową.

A u to m a t z w odą sodową

P ie rw sz y przykład dotyczy automatu, k tó ry w ydaje puszkę z wodą sodową po w rzuceniu m onety półdolarowej lub dwóch monet ćw ierćdolarow ych. N a rysunku przedstawiono prostą specyfikację w łaściw ości bezpieczeństwa tego autom atu uwzglę­

dniając w aru n ek początkowy, że autom at rozpoczyna pracę w stanie I. Z rysunku w yn ika, że będąc w stanie I autom at może podjąć'akcję związaną z

wrzuceniem m onety ćwierćdolarowej

i przejść do stanu I I lub - związaną z

wrzuceniem monety półdolarowej

i przejść do stanu III. W stanie m może w ystąpić jed yn ie akcja

w yd a n ia puszki,

przeprowadzająca autom at do stanu I. Je s t to specyfikacja bezpieczeństwa, tzn. zapewniająca, że dopuszczalne jest w ystąpienie tylko w ym ienio nych akcji. Nie zapewnia ona jednak, że jak ie k o lw ie k akcje muszą wystąpić.

W yd an ie puszki

m ooeły półdolarowej

S p e c y fik a c ja a u to m a tu z w od ą sodow ą

Co

się stanie, jeśli użytkow nik w rzuci najpierw monetę ćwierćdolarową, a potem półdolarową?

Specyfikacja nie dopuszcza takiego zachowania. N ależy bo­

w iem pamiętać, że dobrane przykłady nie są realistycznym i specyfikacjam i. Istnieją dw a sposoby rozważenia tego aspektu specyfikacji.

• Specyfikacja ogranicza zachowanie użytkow nika, zabrania­

ją c m u w rzucenia m onety półdolarowej po wrzuceniu ćw ierć­

dolarowej.

• Specyfikacja nie określa, co uczyni automat, jeśli użytkow nik w rzuci najpierw monetę ćwierćdolarową, a później półdolarową.

R ealizatorow i pozostawia się swobodę co do konstrukcji autom a­

tu reagującego na ten rodząj „n iew łaściw ego ” zachowania użyt­

kownika.

W yb ó r jednego z tych podejść nie ma w p ły w u na to, ja k się pisze specyfikacje i ja k się ich dowodzi.

R ysunek m iał specyfikować zachowanie autom atu z wodą sodową. Dlaczego zatem specyfikuje on także zachowanie u ży t­

kow nika ?

Nie można zrealizować systemu, k tó ry funkcjonuje w łaściw ie wobec dowolnego zachowania otoczenia. Bardziej realistyczna specyfikacja będzie pozwalała u żytkow nikow i na w rzucenie monet w dowolnej kolejności, na przykład, zakładając w takim przypadku ich zwrot przez automat. N ie będzie jed n ak pozwala­

ła u żytkow nikow i na zaatakowanie autom atu m łotkiem (później stanie się jasne, w ja k i sposób). Specyfikacja procedury zawiera zw ykle w aru n ek początkowy (ang.

precondition),

ograniczający zachowanie otoczenia przez zabronienie wy\yołań, których argu­

m enty nié spełniają tego w arunku. Specyfikacja obwodu elek t­

ronicznego zawiera ograniczenia czasowe, określąjące kiedy otoczenie może zmienić wartości sygnałów w ejściow ych [10].

2

Inform atyka nr 10, 1988

P rzedstaw iony rysunek jest prostym, diagram em przejść stanów

(ang.

state transition diagram). Takie diagram y są użyteczne dla bardzo prostych przykładów , ale czy nie skom pli­

kują się zanadto p rzy specyfikow aniu rzeczyw istych systemów?

T ak, tych diagram ów nie buduje się zbyt łatwo dla większych ' problemów. D iagram y przejść stanów stanowią tylko jeden szczególny język, którego można używ ać w metodzie aksjomatu przejść. W ad y tych diagram ów są ograniczeniami samego ję z y­

ka, a nie - metody aksjom atu przejść. Do pisania specyfikacji większych system ów tą metodą potrzebne są inne języki. Do kwestii językó w wrócę jeszcze w dalszej części a rtyku łu .

Jakie jest zatem fundam entalne, niezależne od języka po­

jęcie w yrażone przez diagram przejść stanów przedstaw iony na rysunku?

S ą to dopuszczalne zm iany stanów. W metodzie aksjomatu przejść specyfikuje się w łaściwości bezpieczeństwa opisując zbiór stanów i wszystkie dopuszczalne przejścia między stanami.

Istnieje w iele różnych języków , za pomocą których można opisywać stany i przejścia między nimi.

Pojęcie zm ia n y stanów zilustrow ane przez diagram na rysunku jest używ a n e od wielu lat. Czy metoda aksjom atu przejść zaw iera cokolwiek ponadto?

Nowością w metodzie aksjom atu przejść nie jest sam diag­

ram, lecz jego interpretacja jako specyfikacji formalnej. T a nowa interpretacja jest potrzebna, ponieważ konwencjonalne metody przejść stanów nie zajmują się w łaściw ie pytaniem , co znaczy dla realizacji spełnienie takiej specyfikacji. Je d n ą z zalet metody aksjomatu przejść jest to, że specyfikacje właściw ości bezpiecze­

ństwa można pisać za pomocą przyjaznej, zrozumiałej notacji, jak np. diagram y przejść stanów. Choć specyfikacje nie w yg lą ­ dają na nowe, nowe jest znaczenie ja k ie im się przypisuje 2).

Co

nowego jest w interpretacji rysu n ku za pomocą metody aksjom atu przejść?

►

K onw encjonalna interpretacja rysunku stwierdza, że specy­

fikuje on autom at trójstanowy. W metodzie aksjomatu przejść uważa się, że istnieje pewna funkcja stanu, powiedzm y f, która przybiera w artości I, I I i III, a diagram specyfikuje ja k zmienia się - funkcja. M ów iąc dokładniej, zakłada się, że autom at z wodą sodową ma pew ien nie specyfikow any zbiór stanów, nazw any S, a zachowanie automatu jest opisane przez ciąg stanów s0, S j , s2, ...

Fu n kcja Stan u f jest odwzorowaniem zbioru S na zbiór wartości {I, II, I I I } . Diagram z rysunku specyfikuje, że dla każdego przejścia stanów

Sj —* Sj + 1

(w tej kolejności) zachodzi albo równość f(s,) = f(Si + i),

co może być praw dziw e naw et wtedy, gdy

si ^ si + x

albo jedna z następujących zmian w artości z f (Sj.) na f (Sj + i):

• f (sp = I, f (Si + i) = I I . a zmiana jest spowodowana przez

wrzucenie m onety ćwierćdolarowej

• f (Sj) = I, f (s( + i) = I I I , a zmiana jest spowodowana przez

wrzucenie m onety półdolarowej

• f (Sj) = II, f (st + i) = I I I , a zmiana jest spowodowana

wrzuceniem m onety ćwierćdolarowej

• f (Sj) = I I I , f (S| +1) = I, a zmiana jest spowodowana

w ydaniem puszki.

11 M ó w ią c dokładniej,, znaczenie to było nowe, gdy je zaproponowano [7, 8]. Później taka interpretacja p o ja w iła się też w in n ych pracach, np. (5],

Co

zyskuje się przez tę nową interpretację?

Rzeczyw isty automat z wodą sodową może mieć setki stanów w ew nętrznych. Je ś li specyfikacja zapewnia, że istnieją trzy, stany, to należy zadać pytanie, co to znaczy dla automatu o setkach stanów, że spełnia on specyfikację zapewniającą istnienie tylk o trzech stanów. Interpretacja w metodzie aksjom a­

tu przejść omija ten problem, ponieważ specyfikacja zapewnia, że funkcja stanu ma tylko trzy wartości, nie m ówiąc nic o liczbie różnych stanów. Z alety tej interpretacji i zagadnienia w y n ik a ją ­ ce z konwencjonalnej interpretacji powyższego rysunku jako automatu trójstanowego zostaną omówione dalej.

Specyfikacja fo rm a ln a pow inna dostarczać wszelkich infor­

macji niezbędnych do określenia, czy realizacja jest popraw na.

Jednakże, z rysu n ku w żaden sposób nie w ynika, czy realizacja m a składać się z:

1) całego u rządzenia włącznie z pojem nikiem na monety i stoja­

kiem na puszki,

2) układu elektronicznego w enątrz m aszyny, 3) program u dla mikroprocesora sterującego.

Dobór etykiet na tukach diagram u może dostarczać pewnych wskazówek, lecz z pewnością nie może mieć żadnego znaczenia form alnego. Czy zarów no pełne urządzenie z wodą sodową,

_

układ elektroniczny, ja k i program kom puterow y mogą być p opraw nym i realizacjam i tej samej specyfikacji form alnej?

Specyfikacja m usi być niepełna, jeśli nie rozróżnia między urządzeniem m echanicznym , układem elektronicznym a prog­

ramem. N a rysunku brakuje specyfikacji

sprzężenia

(ang.

inter-

,

face),

tj. m echanizmu, za pomocą którego system kom unikuje się

z otoczeniem. Specyfikacja musi określać, czy kom unikacja odbywa się przez wrzucanie monet i w ydaw an ie puszek, czy przez zm iany poziomu napięć na przewodach, czy przez w y w o ły ­ w anie i powroty z procedur program owych. Specyfikacja sprzę­

żenia określa, że

wrzucenie m onety

nie może być w ykonane (zastąpione) m łotkiem . Różnica między w rzuceniem monety a użyciem młotka, podobnie ja k m iędzy podaniem sygnału o napięciu 5V a sygnału o napięciu 5kV, może być opisana tylko z użyciem szczegółów realizacyjnych. Sprzężenie musi być zatem specyfikowane na poziomie realizacji.

Jak specyfikuje się sprzężenie?

System i jego otoczenie kom unikują się przez zm iany w artoś­

ci funkcji stanu. Przykładow o, jeśli specyfikuje się układ elektro­

niczny, to kom unikacja między tym układem a jego otoczeniem odbywa się przez zm iany w artości funkcji stanu reprezentujące różne wartości napięć na poszczególnych liniach-” . Każdej linii w może odpowiadać funkcja stanu f w, która reprezentuje napię­

cia na tej linii. Specyfikacja może zezwalać otoczeniu na kom uni­

kow anie się z układem przez zmianę wartości funkcji fw na 4,5 + 1,2 V , tzn. ustaloną w artość napięcia na lin ii między 3,3 V a 5,7 V . Innej linii w ’ mogą odpowiadać wartości funkcji fw, z przedzia­

łu 0 ± 1,2 V . M im o ciągłego zakresu wartości napięcia, system można nadal uważać za dyskretny, ponieważ zm iany napięcia uważa się za chwilow e.

A b y można było specyfikować sprzężenia, należy określić w specyfikacji, ja k zmieniają się takie funkcje stanu sprzężenia.

Można to zrobić tą samą metodą, której użyto do specyfikowania zmian w ew nętrznych funkcji stanu, takich ja k funkcja f w specy­

fikacji automatu z wodą sodową. T ak więc, metoda aksjomatu przejść nie w ym aga żadnego dodatkowego aparatu do specyfiko­

w ania sprzężenia.

W praktyce zw ykle nie specyfikuje się sprzężenia w ten sposób. Sprzężenie jest specyfikowane w języku realizacji, co powoduje, że łatwiejsze jest sprawdzenie poprawności realizacji.

Przykładow o, linie łączące układ elektroniczny z otoczeniem mogą być w yspecyfikow ane bezpośrednio w języku opisu sprzę­

tu użytym do realizacji układu. Zam iast specyfikować, jak zmieniają się rzeczywiste w artości napięcia na lin ii w , można

31 W rzeczywistości specyfikuje się nie układ elektroniczny, lecz model m atem atyczny tego układu. F u n k cje stanu są m atem atycznym i obiektam i tego modelu, które reprezentują napięcia na liniach rzeczywistego układu.

« te ł

opisać te zm iany używ ając elem entarnych operacji języka opisu sprzętu, np.:

w: = tru e

bez podawania rzeczywistych wartości.

Jak specyfikuje się sprzężenia programowe?

Istota specyfikacji sprzężenia zależy od stosowanego języka program owania. D la procedury w Pascalu sprzężenie specyfiku­

je się podając nazwę procedury, typ y jej argum entów oraz nazwy i typ y wszystkich zm iennych globalnych, do których procedura ma dostęp. D la pakietu M oduli 2 sprzężenie specyfikuje się w module definicyjnym [12].

Z naczy

to, że nie można

specyfikować procedury niezależnie od języka, w którym jest zrealizow ana. Czy nie m a zatem możliwości n a p isania specyfikacji, pow iedzm y fu n kcji oblicza­

jącej pierw iastki kwadratowe, która jest niezależna od języka realizacji?

Nie specyfikuje się języka, w którym procedura ma być zrealizowana, lecz specyfikuje się realizację sprzężenia. System , którego sprzężenie jest w yspecyfikow ane jak o procedura pasca- lowa, może być zrealizowany w języku asemblera. P o w in ien jed yn ie odpowiadać tym sam ym konwencjom w yw o ływ an ia, co procedura w Pascalu.

Choć specyfikacje funkcji obliczającej pierw iastki kw adrato­

w e będą podobne dla różnych językó w program owania, nie będą jednak identyczne. Przykładow o, sposób obsługi błędów będzie zależał od tego, czy dany język ma odpowiednie mechanizm y.

Rozdzielenie specyfikacji funkcji obliczającej pierw iastki k w a d ­ ratowe na część wspólną i część należącą do sprzężenia, jest zagadnieniem dotyczącym języka specyfikacyjnego, rozważa­

nym w [3],

W p ły w sprzężenia na resztę specyfikacji jest szczególnie istotny w system ach współbieżnych. W a rtyku le [9] w yk az a ­ no, że specyfikacja naw et tak prostej w łaściwości ja k p rio ry­

tet F IF O nie może być niezależna od szczegółów realizacji sprzężenia.

W ynika stąd, że nawet dla specyfikacji na n a jw yższym poziomie sprzężenie należy specyfikować na poziomie realiza­

cji. Czy nie m ożna ukryć niskopoziomowych szczegółów realiza­

cyjnych w specyfikacji na w ysokim poziomie?

Sprzężenie specyfikuje się opisując, ja k mogą zmieniać się funkcje stanu sprzężenia. Poniżej pokażę, ja k można specyfiko­

w ać hierarchicznie zm iany w ew nętrznych funkcji stanu. To samo podejście można zastosować do funkcji stanu sprzężenia.

Jed n akże specyfikacja wysokiego poziomu nie jest pełna dopóty, dopóki nie jest zakończone specyfikowanie sprzężenia aż do poziomu realizacji. P e łn a specyfikacja powinna w yelim in ow ać potrzebę jak ie jk o lw iek kom unikacji między użytkow nikiem system u a jego realizatorem. Przykładow o, specyfikacja układu elektronicznego sterującego automatem z wodą sodową pow in­

na zawierać wszystkie inform acje niezbędne osobie projektują­

cej pozostałą część urządzenia, tzn. powinna określać rzeczywis­

te w artości napięć na poszczególnych liniach.

O ile hierarchiczna dekompozycja sprzężenia jest użyteczna w praktyce, to logicznie jest jed yn ie metodą organizowania specyfikacji wysokiego poziomu. Dlatego nie będę rozważał takiej dekom pozycji sprzężenia.

Czy

sprzężenie m ożna specyfikować jedynie p rzy użyciu fu n k c ji stanu?

Oprócz funkcji stanu sprzężenia, trzeba wprowadzić także pojęcie odpowiedzialności za zm iany w artości tych funkcji stanu.

Specyfikacja sprzężenia autom atu z wodą sodową musi określać, że otoczenie (tzn. użytkow nik) w ykonuje

wrzucenie monety ćwierćdolarowej

lub

wrzucenie monety póldolarowej,

a system (tzn. autom at) w yko n u je

w yd a n ie puszki.

Specyfikacja sprzęże­

nia procedury musi stwierdzać, że otoczenie (tzn. pozostała część

program u) w ykonuje w yw o łan ie procedury, a system (tzn.

procedura) w ykonuje powrót.

Zazwyczaj akcje są w yk o n yw an e albo przez otoczenie, albo przez system. Jed n akże niekiedy użyteczne jest zapewnienie, że określona część system u w ykonuje akcję. Przykładow o, aby w yspecyfikow ać proces współdziałający ze swoim otoczeniem zarówno przez zmienne współdzielone, ja k i przez operację typu C S P [4], użyteczne może być rozdzielenie akcji w yk o n yw an ych przez kan ał ko m u n ikacyjn y (operacje ! i ?) od w yk o n yw an ych przez inne procesy (operujące zm iennym i w spółdzielonym i)41.

Dlaczego konieczne jest określenie, kto w ykonuje akcje sprzężenia ?

Rozw ażm y pakiet M oduli 2, k tó ry realizuje kolejkę dostar­

czając procedur p u t i get. Je ż e li nie poda się w specyfikacji, że tylko otoczenie może w yw o ła ć te procedury, to specyfikacja będzie spełniona przez realizację, która sama w yw o łu je procedu­

rę put, powodując dodawanie przypadkow ych elem entów do kolejki.

Jaka jest ogólna postać specyfikacji

w łaściw ości

bezpie­

c z e ń s tw a ^ metodzie aksjom atu przejść?

Na specyfikację w łaściw ości bezpieczeństwa składają się następujące elem enty:

• zbiór funkcji stanu rozdzielonych na wew nętrzne funkcje stanu i funkcje stanu sprzężenia,

• specyfikacja w artości początkowej każdej funkcji stanu,

• zbiór akcji rozdzielonych na akcje w ew nętrzne i akcje sprzężenia,

• specyfikacja, kto w ykonuje akcję sprzężenia (dla każdej takiej akcji) - akcje w ew nętrzne są w yk o n yw an e przez system,

• zbiór reguł zw anych aksjom atam i przejść, które określają, ja k każda akcja zmienia funkcje stanu (funkcja stanu sprzężenia

może być zmieniona tylko przez akcję sprzężenia).

W przykładzie automatu z wodą sodową jest jedna w ew nętrz­

na funkcja stanu f, o w artości początkowej I. Fu n kcje stanu sprzężenia nie są w yspecyfikow ane. Ponadto są trzy akcje będące akcjam i sprzężenia:

w rzucenie m onety ćwierćdolarowej

i

w rzucenie m onety półdolarowej

w yk o n yw an e przez otoczenie

oraz w ydanie pu szki

w yk o n yw an e przez system. S k u tek

w rzu ­ cenia monety ćwierćdolarowej

jest opisany przez aksjomat przejścia zapewniający, że ta akcja może w ystąpić tylk o wtedy, gdy f równa się I, co powoduje zmianę wartości funkcji na I I , lub wtedy, gdy f równa się II, co powoduje zmianę jej w artości na II I . R eg u ły odpowiadające

w rzuceniu m onety półdolarowej i w y d a ­ niu puszki

są podobne, lecz nieco prostsze. P e łn a specyfikacja autom atu z wodą sodową musi również uwzględniać fakt, ja k te trzy akcje zmieniają funkcje stanu sprzężenia.

Jakie jest dokładne znaczenie takiej specyfikacji?

Fo rm aln ym znaczeniem specyfikacji w metodzie aksjomatu przejść jest formuła logiki tem poralnej. A b y podać ścisłą defini­

cję tego znaczenia, należy zdefiniować sem antykę formalną logiki tem poralnej i podać algorytm tłum aczenia specyfikacji na form ułę tej logiki. Uczyniono to w a rtyk u le [7], Poniżej, zamiast takiego formalnego podejścia, spróbuję przedstawić intuicyjne rozumienie znaczenia specyfikacji metodą aksjom atu przejść, przez szczegółowe rozważenie, co znaczy zrealizowanie specyfi­

kacji.

Rozważając intuicyjne rozumienie specyfikacji w metodzie aksjom atu przejść, należy znać ogólną postać form uły specyfika- cyjnej. Po m ijam przy tym część specyfikacji dotyczącą tego, kto w ykonuje akcje. Niech fj,..., fn będą w ew nętrznym i funkcjam i stanu, a

gl

gm

funkcjam i stanu sprzężenia tej specyfikacji.

1 Choć często m yśli się o ko m unikacji ty p u C S P ja k i o a k cji w y k o n y w a n e j łącznie przez nad aw cę i odbiorcę, uznanie je j za akcję k anału elim in u je konieczność w prow adzania pojęcia akcji łącznych.

d okończenie n a I I I okł.

4

Inform atyka nr 10, 1988

I n s t y t u t I n f o r m a t y k i :!!: ii:: T O W A R Z Y S T W O *y Je s ie n n e j P T I „W sp ó łcz e sn e k ie r u n k i ro z w o ju in f o r m a ty k i”

r r . . . , _ r , . . : : : : I N F O R M A T Y C Z N E - M rą g o w o , 4-8 listo p ad a 1985 r.

U niw ersytet W rocławski

M A C IE J M . S Y S Ł O

P O L S K I E P ie rw s z a w e rs ja a r t y k u łu została prz e d staw io n a podczas Szko-

Maszyny i algorytmy równoległe (1 )

A rty k u ł ten jest przeglądem modeli maszyn równoległych oraz zaprojektowanych dla nich algorytm ów. Zilustrow ano pod­

stawowe metody uwspółbieżniania obliczeń: potokowość, rozsy­

łanie i kum ulację oraz najpopularniejsze modele maszyn rów no­

ległych: M IM D (tj. wieloprocesory), S IM D z różnym i sieciami połączeń między procesorami oraz m aszyny systoliczne. D ziała­

nie maszyn rów noległych zilustrowano na przykładach pocho­

dzących z dwóch dziedzin: operacji m acierzowych i porządkowa­

nia. Operacje m acierzowe charakteryzują się naturalną współ- bieżnością tkw iącą w sam ych problemach; ich algorytm y rów no­

ległe są najczęściej odpowiednim i realizacjam i klasycznych metod rozwiązywania. Porządkow anie natomiast w ym aga ca ł­

kiem now ych metod realizacji na m aszynach rów noległych i jest w ykon yw an e za pomocą wąsko w yspecjalizow anych algoryt­

mów zw anych sieciam i porządkującym i, złożonych z pewnej liczby prostych m odułów porównań.

M A S Z Y N Y I A L G O R Y T M Y R Ó W N O L E G Ł E

W yróżnić można dw a podstawowe sposoby przyspieszania kom puterów: jeden polega na stosowaniu coraz szybszych ele­

mentów elektronicznych, a drugi na zastosowaniu współbieżno- ści obliczeń. Pie rw sz y był siłą napędową rozwoju kom puterów od ch w ili zbudowania pierwszej elektronicznej m aszyny cyfro­

wej E N IA C w 1946 roku, drugi zaś pojaw ił się dopiero na początku lat sześćdziesiątych, najpierw w rozważaniach teorety­

cznych, gdy zaczęto interesować się algorytm am i równoległym i.

Pierw szy ze sposobów przyspieszania obliczeń jest całkow icie uzależniony od dostępnej technologii, drugi natomiast może być rozwijany niezależnie od sprzętu kom puterowego. Po m ysł u- współbieżnienia obliczeń pojaw ił się niem al w tym samym czasie, co konstrukcja pierwszej maszyny. Charlesa Babbage’a (1791 1871), konstruktora pierwszej zachowanej do dzisiaj m a­

szyny liczącej, zainspirow ały tablice logarytm iczne, których w ykonanie mogłoby pochłonąć jedno całe życie; zostały jednak sporządzone w ciągu k ilk u lat przez zespół 6 uczonych, 8 wyszkolonych pom ocników i około 60 rachm istrzów w yk o n u ją ­ cych jed yn ie dodawanie i odejmowanie. Z tego przykładu organi­

zacji obliczeń (współbieżnych, zauważm y!), Babbage zrealizował jedynie ideę maszyny, która m iała autom atyzować w yko n yw an ie takich sam ych działań. W późniejszych latach swej działalności zauważył jednak także, że takie obliczenia można by w y k o n y ­ wać za pomocą maszyny, która potrafiłaby produkow ać wiele w yn ikó w w tej samej ch w ili czasu. Idea ta pojaw iła się ponownie dopiero wówczas, gdy rozwój elektro n iki przybliżył moment zbudownia pierwszej m aszyny równoległej.

W arto w yjaśnić w tym miejscu różnicę między określeniam i ró w n o leg ły (ang.

parallel)

i w spó łbieżn y (ang.

concurrent).

To pierwsze będzie w tym a rtyku le używ ane przeważnie w odnie­

sieniu do obiektów statycznych, drugie zaś do procesów. Zatem równoległy może być algorytm lub maszyna. Współbieżne są natomiast w yk o n yw an e w maszynie procesy lub program y będące im plem entacjam i algorytm ów równoległych. M ó w im y więc o program owaniu współbieżnym.

Bardzo często będą zamiennie używ ane określenia maszyna i algorytm. A lg o rytm y równoległe są bowiem nierozerw alnie związane z modelem (lub konkretną maszyną) obliczeń, dla których zostały opracowane.

A lgo rytm równoległy można zdefiniować jak o zbiór niezależ­

n ych zadań, które w ykon u ją się jednocześnie, kom unikując się nawzajem, by korzystać ze swoich w y n ik ó w obliczeń. K la s y fik a ­ cja algorytm ów rów noległych na ogół po kryw a się z klasyfikacją maszyn równoległych, dla których zostały opracowane. W ię k ­ szość algorytm ów rów noległych można sklasyfikow ać w g meto­

dy sterowania współbieżnością, w ielkości rozdrobnienia zadań i geom etrii sieci kom unikacyjnej.

Sterow anie współbieżnością jest potrzebne do zapewnienia poprawności obliczeń, w k tórych w ięcej niż jedno zadanie może być w yk o n yw an e równocześnie. *W tym celu są wym uszane współdziałania między różnym i zadaniami. Najogólniej, oblicze­

nia mogą być synchroniczne dzięki scentralizowanej kontroli, i asynchroniczne, gdy na przykład sterowanie odbywa się za pomocą w spólnych danych.

Stopień rozdrobnienia algorytm u równoległego można okre­

ślić m aksym alną w ielkością obliczeń w yk o n yw a n ych przez zadanie, zanim ma nastąpić kom unikacja z inn ym i zadaniami.

D la przykładu, algorytm y o bardzo dużym rozdrobieniu w y m a ­ gają zw ykle dość częstej kom unikacji m iędzy zadaniami, a zatem stosunkowo dużą część obliczeń zajmuje kom unikacja.

Na podstawie m etody sterowania współbieżnością i w ielkości rozdrobnienia zadań, w yróżnia się trzy podstawowe typ y m a­

szyn równoległych: M IM D , S IM D i m aszyny systoliczne.

Maszyna M IM D (ang.

m ultiple instruction m ultiple data),

zwana także maszyną wieloprocesorową, składa się z pewnej liczby działających asynchronicznie procesorów, z których każ­

dy ma niezależny licznik rozkazów i w ykonuje swój w łasny program, korzystając przy tym ze wspólnej dla wszystkich procesorów pamięci. Rozdrobnienie zadań w algorytm ach dla maszyn M IM D jest zw ykle niew ielkie i poszczególnym proceso­

rom są przydzielane całe fragm enty obliczeń, np. w yw ołan ia procedur. M aszynam i są C.mmp, Cm* i Pluribus.

W m aszynach S IM D (ang.

single instruction m ultiple data)

procesor centralny steruje pozostałymi procesorami w ysyłając do wszystkich taką samą instrukcję, która jest w yk o n yw a n a na danych umieszczonych w lo kaln ych pam ięciach procesorów.

Działanie maszyn S IM D jest w ięc synchroniczne. W ielkości zadań obliczeniowych dla poszczególnych procesorów są średnie lub małe. Przykład em m aszyny S IM D jest Illia c IV złożona z 64 procesorów.

G w a łto w n y rozwój m ikro elektroniki w ostatnich latach zre­

wolucjonizow ał także konstrukcje kom puterów. Technologia V L S I pozwala obecnie umieszczać w jed n ym układzie (kostce, ang.

chip)

dziesiątki, a naw et setki tysięcy elem entów. D oprow a­

dziło to między inn ym i do powstania całych maszyn (proceso­

rów) w pojedynczych układach, a wśród nich tzw. m aszyn systo licznych, które mogą być częściami składow ym i inn ych potężniejszych kom puterów. M aszyna systoliczna jest regularną siatką elem entarnych procesorów o bardzo wąsko wyspecjalizo­

w an ym przeznaczeniu, przez które rytm icznie przepływ ają da­

ne. Je s t to w ięc m aszyny synchroniczna ze stałym bardzo dużym rozdrobnieniem zadań.

Ja k łatw o zauważyć, procesory (w skrócie P ) w m aszynach M IM D są zw ykle pełnym i jednostkam i operacyjnym i wyposażo­

n ym i w e wszystkie podstawowe operacje. W maszynach S IM D rola procesorów jest zw ykle ograniczona do w yk o n yw a n ia tylko pewnego podzbioru operacji. W maszynach systolicznych nato­

miast procesory w ykon u ją najczęściej tylk o jedną operację arytm etyczną (i k ilk a przesłań). Z tego względu procesory w m aszynach systolicznych, a czasem także i w maszynach S IM D , są nazyw ane e le m e n ta rn y m i p rocesoram i (ang.

Proces­

sing element

), w skrócie P E .

Sieć połączeń m iędzy procesorami w maszynie równoległej może przyjm ow ać różnorodną postać. Bezpośrednie połączenia między procesorami określają kom unikację m iędzy zadaniami w yk o n yw a n ym i przez poszczególne procesory. D la przykładu, procesory mogą być umieszczane w w ierzchołkach drzewa binarnego, którego krawędzie wyznaczają m ożliwe drogi bezpo­

średniej kom unikacji między procesorami. Procesory elem entar­

ne mogą tw orzyć jedno- lub w ielo w ym iaro w ą sieć, np. liniową, kw adratow ą lub sześcienną.

Pow yższa taksonom ia m aszyn równoległych, której schemat został zaczerpnięty od K u n g a [1], ma swoje odbicie w algoryt­

m ach równoległych. Zatem , dla przykładu, algorytm równoległy opracowany dla maszyn S IM D z siecią kw adratow ą nazyw am y algorytm em S IM D z siecią kw adratow ą itp. Podobnie definiuje się algorytm y systoliczne i M IM D .

W algorytm ach systolicznych zadania dla poszczególnych procesorów elem entarnych Są bardzo proste, a kom unikacja między P E dość częsta. A lg o rytm y systoliczne są im plem ento­

w ane zw ykle bezpośrednio w postaci odpowiednich układów.

Z algorytm am i M IM D sytuacja jest niem al odwrotna - są one przeznaczone do w yk o n yw an ia w systemach wieloprocesoro­

w ych o ogólnym przeznaczeniu. A lg o rytm y S IM D można sklasy­

fikow ać m iędzy dwom a pozostałymi typam i. N a ogół każdy algorytm systoliczny ma odpowiednik w postaci algorytm u S IM D , w którym poszczególne zadania mają mniejsze rozdrob­

nienia. N ie każdy jednak algorytm S IM D może być zrealizowany przez maszynę systoliczną.

Z Ł O Ż O N O Ś Ć I E F E K T Y W N O Ś Ć A L G O R Y T M Ó W R Ó W N O ­ L E G Ł Y C H

Ocena efektyw ności algorytm ów (i maszyn) równoległych powinna dostarczyć pewnej m iary przyspieszenia obliczeń, osią­

gniętego dzięki użyciu w ielu procesorów. W sytuacji idealnej maszyna z p procesorami powinna redukow ać czas obliczeń p-krotnie. D la w ie lu problem ów nie udało się jednak dotychczas tego osiągnąć.

Definicja złożoności czasowej (lub czasu obliczeń) algorytm u równoległego jest naturalnym rozszerzeniem określenia złożo­

ności algorytm u sekwencyjnego. Fu n kcja f(n) jest złożonością algorytm u równoległego, jeśli czas od ch w ili rozpoczęcia pracy przez pierwszy z procesorów m aszyny do ch w ili zakończenia p racy przez wszystkie procesory nie przewyższa f(n) dla każdego zadania problem u o rozmiarze n. D la przykładu, algorytm sekw en cyjn y obliczający sumę n liczb ma złożoność 0(n), gdyż w ykonuje (n — 1) dodawań. Je ś li dodawania mogą być w y k o n y ­ w ane współbieżnie i dysponujem y In/log nl procesorami, to suma n liczb może być obliczona w 2[log nl krokach za pomocą m aszyny drzewiastej. Zatem równoległy algorytm dodawania n liczb ma złożoność 0(log n) przy użyciu n/log n procesorów.

Liczba procesorów tw orzących maszynę równoległą będzie oznaczana przez p, a funkcja złożoności algorytm u równoległego dla takiej m aszyny - przez tp(n). Zatem tjin ) jest złożonością algorytm u sekwencyjnego. D la w ie lu maszyn, problem ów i algo­

rytmów’ funkcja tp(n) jest określona tylk o dla pew nych p, a czasem tylk o dla jednej wartości p zależnej od rozm iaru problemu. Je ś li p nie jest ograniczone, to m ów i się o n ie o g ra n i­

czonej ró w n o leg ło ści (ang.

unbounded parrallelism ).

Iloraz:

sp(n) = tj(n)/tp(n)

nazyw a się przyspieszeniem (ang.

speedup)

algorytm u ró w nole­

głego, zaś:

ep(n) = sp(n)/p

e fe k tyw n o ś cią (ang.

efficiency)

algorytm u. W definicji przyspie­

szenia, za tj(n ) przyjm uje się najczęściej złożoność najlepszego algorytm u sekwencyjnego. Przyspieszenie jest m iarą ulepszenia algorytm u sekwencyjnego przez algorytm równoległy, e fektyw ­ ność zaś określa stopień w ykorzystania równoległości. Inną m iarą efektyw ności algorytm u równoległego, uwzględniającą czas obliczeń i liczbę procesorów, jest koszt (ang. cost) algorytm u zdefiniowany jako:

*

c p(n) = p ■ tp(n)

Oczywiste są następujące nierówności:

Sp(n) ^ p czyli

tj(n ) sg ptp(n) = cp(n) oraz

ep(n) < 1

gdyż algorytm rów noległy o złożoności tp(n) może być sym ulo­

w an y przez algorytm sekw en cyjn y w czasie 0(cp(n)). W arto zauważyć, że e^n ) = 1, zatem celem niekoniecznie jest o ptym ali­

zacja ep(n) przez w ybór odpowiedniej liczby procesorów. D la wspomnianego wyżej równoległego algorytm u obliczania sumy n liczb jest

tp(n) = 2 flog nl,

gdzie p = [n/log nl, zatem sp(n) jest rzędu p/2, a ep(n) - w p rzybli­

żeniu 1/2, czyli procesory są w yko rzystyw an e przez ten algorytm średnio w 50%.

Algo rytm równoległy, dla którego sp(n) = p, ma o p tym aln y w spółczynnik przyspieszenia obliczeń (jeśli sp(n) jest 0(p), to m ówi się o przyspieszeniu optym alnym z dokładnością do stałego w spółczynnika proporcjonalności). Pow odem tego, że w iele algorytm ów równoległych nie osiąga optym alnego przy­

spieszenia, może być np. to, że:

• problem nie daje się podzielić na podproblem y o praw ie tych sam ych rozmiarach,

• korzystanie z zasobów pam ięci (zw ykle w spólnych) wydłuża pracę procesorów,

• zapewnienie synchronizacji między procesorami pochłania dodatkowy czas.

P R Z E T W A R Z A N I E P O T O K O W E

Je d n y m z najwcześniej zastosowanych podejść do współbieżności obliczeń było p rz e tw a rz a n ie potokow e (ang.

pipelining).

Najogólniej m ówiąc, potokowość obliczeń jest reali­

zowana przez podział w ielokrotnie powtarzanego procesu sek­

w encyjnego na podprocesy, z których każdy jest w yk o n yw a n y przez niezależny m oduł pracu jący równocześnie z in n ym i m odu­

łami.

Ja k o przykład można rozważyć proces w yko n an ia instrukcji, w którym w yróżnić można przynajm niej cztery podprocesy:

pobranie in strukcji IF , zdekodowanie operacji ID , pobranie argum entów O F oraz w ykonanie E X E C . Na rysunku 1'zilustro- w ano potokowe przetwarzanie instrukcji. T en typ potokowości jest realizow any na poziomie system u operacyjnego. Do niższego poziomu można zaliczyć potokowe jednostki arytm etyczne. D la przykładu, w procesie dodawania dwóch liczb zm iennoprzecin­

k ow ych można w yróżnić następujące podprocesy, które mogą być realizowane potokowo:

- w ydzielenie cech (w ykła d n ik ó w ) obu liczb, - porównanie cech,

- przesunięcie m antysy jednej z liczb w celu zrównania cech, - dodawanie mantys,

- norm alizacja sumy,

6 Inform atyka nr 10. ¡9X8

- badanie nadm iaru łub niedomiaru.

Oba typ y potokowości zastosowano już w latach sześćdziesią­

tych w kom puterze I B M 360/91, a obecnie są realizowane w większości superkom puterów, np. w T I A S C , C D C 6600, C D C S T A R 100, Am dahl 470 V/6 i C R A Y 1 (te dw a ostatnie uznaje się za kom putery czwartej generacji).

W y k o n a n i e I n s t r u k c j i Procesor ntepotokowy

IF OF EXEC

Procesor potokowy

EXEC 1 2 3

OP 1 2 3 L

ID 1 2 3 u

IF 1 2 3 L

□¡ogram czasowy '

R ys . 1. P o to k o w e w y k o n a n ie in s tr u k c ji

Jed n ą z podstawowych m iar oceny działania system u jest jego w spółczynnik przepustow ości (ang.

throughput rate),

defi­

nio w any jak o liczba w yn ik ó w (lub w yko n an ych instrukcji) w jednostce czasu. Potokowość obliczeń jest jedną z metod zwiększania przepustowości systemów. Po w ró ćm y do przykła­

du z rys. 1. Je ś li czas w yko n an ia instrukcji przez procesor niepotokowy wynosi:

T = tj + tt + t3 + t4 t = m ax {tj, t2, t3, t4}

to odpowiednie w spółczynniki przepustowości wynoszą 1/T i l/t.

W szczególności, jeśli wszystkie t[ są sobie równe, to potokowość jest źródłem czterokrotnego zwiększenia przepustowości.

Uzasadnieniem użycia potokowości jest przyjęcie założenia, że ten sam ciąg operacji (instrukcji) będzie powtarzał się bardzo często. Id ealn ą sytuacją dla przetwarzania potokowego są obli­

czenia związane z w ektoram i, np. dodawanie dw óch w ektorów.

Kom p utery, zdolne w sposób potokowy w yk o n yw a ć operacje na całych w ektorach, nazyw a się k o m p u te ra m i w e k to ro w y m i (ang.

vector computers).

T akim i m aszynam i są np. S T A R 100 i C RAY-1. D la uproszczenia operacji przesyłania zawartości pamięci, w kom puterze S T A R 100 zakłada się, że w ekto r może być utworzony jed yn ie przez kolejne kom órki pamięci, a w m a­

szynie CRAY-1 składowe w ektora mogą znajdować się w kom ór­

kach pam ięci o num erach tworzących ciąg arytm etyczny. Z a u ­ ważm y, że w drugim w yp ad ku wiersze i kolum ny m acierzy są wektoram i, w pierwszym zaś - tylk o jeden typ linii, w zależności od sposobu pam iętania macierzy.

N a rysu ku 2 przedstawiono potokowy sum ator w ektorów o składow ych naturalnych. Su m ator ten tw orzy sumę dwóch w ektorów

(Ul U 2, U 3,...) i (V j, V 2, V 3,...), gdzie:

■Uj = UjiUj2... uJk V j = V jiV ja ... v Jk

są bin arn ym i reprezentacjam i składowych.

Czas w yk o n an ia operacji w ektorow ej składa się z dwóch członów: początkowego opóźnienia coraz czasu pojaw ienia się kolejnych w yn ik ó w

x.

Zatem czas w yko n an ia operacji na w ekto ­ rach długości N w ynosi

a

+ Nt. D la przykładu, w komputerze S T A R 100 dla dodawania w ektoró w m am y ^t = 0,6 i

a

= 71, a dodawanie dwóch skalarów trw a t = 13 (czasy te są podane w jednostkach cyk lu podstawowego, k tó ry w ynosi 40 nanose^

kund). Zatem w tym w yp ad ku zastąpienie operacji skalarnych

jedną operacją w ektoro w ą zrealizowaną potokowo jest o płacal­

ne począwszy już od N = 6 (w ogólnym wypadku, dla N > <r/( t - t ).

Co więcej, im dłuższe są w ektory, tym mniejszy jest w p ły w wartości

a

na czas obliczeń, gdyż nąjczęściej

a

» t.

F

VU v23 v32

R y s . 2. P o to k o w y s u m a to r w e k to ró w o s k ła d o w y c h n a tu r a ln y c h

Po to k o w y sum ator w ektoró w z rys. 2 można uznać za maszynę S IM D , a naw et może być zrealizowany przez układ systoliczny. M oim celem jest jednak naszkicowanie ogólnej idei przetwarzania potokowego, które historycznie było pierwszą zrealizowaną koncepcją obliczeń w spółbieżnych [2], Zastosowa­

nie potokowości w m aszynach S IM D , a zwłaszcza w algorytm ach systolicznych, zilustrowano w dalszej części artykułu, poświęco­

nej szczegółowemu om ówieniu trzech podstawowych typów maszyn i algorytm ów równoległych: M IM D , S IM D i systolicz­

nych. P rz y k ła d y problem ów i algorytm ów pochodzą z dwóch obszarów: obliczeń m acierzowych i sortowania. P ro b le m y z pier­

wszej dziedziny, tak w swoim sform ułowaniu, ja k i klasycznych algorytm ach rozwiązywania, charakteryzują się zw ykle jaw n ie w ystępującą w nich równoległością. Zatem równoległe algoryt­

m y m acierzowe są często im plem entacjam i klasycznych algoryt­

m ów m acierzowych, które zw ykle nie są najszybszymi algoryt­

mam i sekw encyjnym i. Sorto w anie zaś jest tym problemem, dla którego obliczenia współbieżne w ym agają metod całkowicie odm iennych od klasycznych,

j.e

względu na n iew ielkie m ożliwo­

ści uwspółbieżniania tych drugich.

L I T E B A T U R A

[11 K u n g H. T.: T h e S tru ctu re o f P a ra lle l Algorithm s. Advan ce s in Com puters, V ol. 19, pp. 65-112, 1980

[2] R am m am o o rth y C. V ., L i H. F.: P ip e lin e A rch itecture. Com p uting S u rve y s , No. 9, pp. 61-102, 1977.

Efektyw ność systemu dBase III

dokończenie ze s. 16

Bad ania w yk az a ły znikom y w p ły w rozm iaru relacji w yn ik o ­ w ej na efektywność polecenia JO IN . Natom iast istotny w p ły w na jego efektyw ność ma typ atrybutu połączeniowego. Je ś li atryb u ­

ty połączeniowe są typu numerycznego, to czas w yk o n yw a n ia polecenia J O I N przedłuża się blisko trzykrotnie. Je s t to związane z przeprowadzaniem każdorazowo konwersji liczb.

• • *

Z przedstawionych w yn ik ó w widać, że system dBase I I I powinno się przede wszystkim stosować do zarządzania bazami danych o prostym schemacie. W w ypad ku baz danych o złożo­

nym schemacie, w ym agających stosowania operacji JO IN , nale­

ży liczyć się ze znacznym obniżeniem efektywności systemu.

L I T E R A T U R A

{ '] K ró lik o w s k i Z., C e lla ry W .: W stęp do projektow ania baz d anych d Base III. W N T , W arszaw a, 1988

[2] d B ase H I. U ser M a n u a ł.‘Ashton-Tate, 1984.

HENRYK GIZDON ADAM PAWLAK

WŁODZIMIERZ WRONA Instytut E lektroniki Politechnika Śląska G liwice

VHD L - Ada języków opisu i projektowania sprzętu /

H is to ria ję z y k ó w opisu sprzętu (ang.

h a rd w a re description languages)

[1, 2, 3, 7, 8, 13] m a ponad trzydzieści lat. W tym okresie k o rzystan o z n ich najczęściej w śro d o w isk u a k a d e m i­

ckim . R zadko n ato m iast u ż y w a ł ich p ro jek tan t- in ż yn ier, przede w sz ystk im z powodu ograniczonej zdolności w iększoś­

ci ję z y k ó w do re p rez e n to w a n ia pro blem ó w p r a k t y k i pro­

je k to w e j oraz frag m en tarycz n eg o c h a ra k te ru o fe ro w a n yc h w sp o m ag ających narzędzi p ro g ram o w ych . S y tu a c ja ta zm ie­

n ia się je d n a k stopniow o w ra z z ro zw ojem technolog ii w y t w a ­ rz a n ia u k ła d ó w scalo nych. Ś ro d o w isk o p ro je k ta n ta sprzętu m usi u lec przeobrażeniu, b y mógł on sprostać ro snącej złożo­

ności u k ła d ó w V L S I. N iezbędnym elem entem tego śro d o w is­

k a p o w in ie n stać się system ko m pu tero w o wspom aganego p ro je k ta n ta , w s p ie ra ją c y i e w e n tu a ln ie z astępu jący p ro je k ­ ta n ta na ró żnych etapach procesu p ro je k to w a n ia . Je s t zupeł­

nie oczyw iste, iż w ta k im n o w ym dla siebie śro d o w isk u p ro je k ta n t stan ie w obec podstaw ow ego problem u p rz ek a z y­

w a n ia sw o ich kon cep cji p ro je k to w yc h k o m p u tero w i.

Ję z y k opisu sprzętu może stać się uniw ersalnym językiem projektanta, w którym w yrażać on będzie swoje idee projektowe czy stru k tu ry konkretnych rozwiązań, i który, porządkując i form alizując koncepcje projektanta, um ożliw i kom puterowi zw eryfikow anie ich poprawności.

A b y język opisu sprzętu mógł zostać uznany za uniw ersalne narzędzie projektanta powinien:

• być użyteczny w całym procesie projektowania,

• zawierać naturalne dla projektanta m echanizm y na każdym z jego etapów,

• być językiem ogólnie akceptow anym przez środowisko pro­

jektan tó w sprzętu.

W ym agań tych nie spełnia żaden z ponad stu proponowanych języków . B r a k jest ogólnie akceptowanego standardu w tej dziedzinie, a ponadto proponowane jęz yki bardzo rzadko obe­

jm ują cały proces projektow ania, zmuszając projektanta do korzystania z w ielu różnych narzędzi.

Potrzeba opracowania nowego, ogólnie akceptowanego jęz y­

ka opisu sprzętu ujaw niła się już w połowie lat siedemdziesią­

tych. Pow ołano wówczas m iędzynarodową grupę roboczą w celu opracowania języka Conlan [lO H an g.

CONsensus LANguage).

Gru pa ta opracowała propozycję jęz yka bazowego o nazwie Base Conlan, z którego mogą być form alnie w yprow adzane nowe jęz yki opisu dla specyficznych dziedzin projektow ania sprzętu.

Z byt późne (w stosunku do potrzeb środowiska) opracowanie i w ydanie raportu C onlanu [9], złożony m echanizm generow ania now ych jęz ykó w oraz brak dostępnych narzędzi program owych wspom agających potencjalnego użytko w n ika C onlanu spowo­

dowały, iż to interesujące naukowo przedsięwzięcie nie zaowo­

cowało ogólnie akceptow anym standardem.

N ow ą i - ze względu na sponsora najpoważniejszą propozy­

cją standardu w dziedzinie językó w opisu sprzętu jest język V H D L , który może być uznany A dą językó w opisu i projektow a­

nia sprzętu11 (ang.

hardw are description and design languages)

[3]. Oba te jęz yki łączy bowiem w iele związków, np. analo­

giczne przyczyny powstania, budowa, ten sam sponsor.

G E N E Z A J Ę Z Y K A V H D L

W lipcu 1983 ro ku zespół złożony z przedstaw icieli firm y Interm etrics, IB M oraz Texas Instrum ents, na zlecenie D ep arta­

m entu O bron y Stan ó w Zjednoczonych rozpoczął pierwszy etap pracy, której celem było zaprojektowanie oraz zaim plem ento­

w anie standardowego języka opisu i projektow ania układów V L S I. P o rocznym okresie projektow ania i dwum iesięcznym okresie w eryfik acji projektu, przystąpiono do pierwszej im ple­

m entacji języka. W jej w yn ik u w grudniu 1985 roku otrzym ano pierwsza w ersję narzędzia napisanego w jęz yku A d a dla kom pu­

terów klasy V A 11/780 i I B M 370.

P ro je k t języka V H D L jest częścią kom pleksowego program u Departam entu O brony U S A o nazwie V H S IC (ang.

very high speed integrated circuits

), którego realizację rozpoczęto w m ar­

cu 1980 roku. Jeg o głów nym zadaniem jest opracowanie efekty­

w n ych metod projektow ania oraz w ykorzystania najbardziej złożonych i bardzo szybkich układów scalonych (o szerokości ścieżek

/.

< 1 um). W najbliższej przyszłości V H D L stanie się obowiązującym językiem projektow ania układów V L S I dla w szystkich kontrahentów Departam entu Obrony.

Z a d a n ia ję z y k a

V H D L ma spełnić podobną funkcję w dziedzinie projektow a­

nia sprzętu, ja k jęz yk A d a w dziedzinie jęz yk ó w program owania.

Ja k o język standardowy, V H D L ma więc:

• wspierać metodologię systematycznego, hierarchicznego pro­

jek to w an ia sprzętu,

• um ożliwiać opis projektu oraz jego sprawdzenie w całym procesie jego powstawania (tj. na różnych poziomach abstrakcji),

• um ożliwiać gromadzenie doświadczeń projektantów (najlep­

sze rozwiązania wchodzą w skład biblioteki projektów),

• zapewniać m ożliwość w ykorzystania w projektow an ym u k ła ­ dzie ostatnich osiągnięć w dziedzinie technologii,

• um ożliw iać generowanie n o w ych w ersji projektów realizow a­

nych w n o w ych technologiach na podstawie rozwiązań projekto­

w ych przechow yw anych w bibliotece projektów,

• ułatw iać dokum entow anie projektu,

• ułatw iać w ym ian ę inform acji między projektantam i oraz całym i zespołami projektow ym i.

Je d n y m z g łów nych wym agań, które postawiono przed projekta­

ntam i języka V H D L jest zastosowanie A d y zarówno do definicji języka ( V H D L adaptuje bez zmian w iele konstrukcji A d y), ja k i do jego w spom agających narzędzi (są im plem entow ane w ję z y ­ ku Ada).

11 Je s t to coraz częściej stosow any term in o m aw ian ej g rup y ję z yk ó w ko m putero w ych, a k centujący zw iązek ję z yk a z procesem p rojektow ania.

8 Inform atyka nr 10. I9XS