1 / 42

STATES IN DISTRIBUTED SYSTEMS

Distributed Operating Systems – Sharif University of Technology. STATES IN DISTRIBUTED SYSTEMS. Lecturer: Dr. R.Jalili. خیلی از مسایل مهم در DSs به جواب‌هایی نیاز دارند که در آن‌ها باید یک ویژگی سراسری تشخیص داده شود.

jesus
Télécharger la présentation

STATES IN DISTRIBUTED SYSTEMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed Operating Systems – Sharif University of Technology STATES IN DISTRIBUTED SYSTEMS Lecturer: Dr. R.Jalili

  2. خیلی از مسایل مهم در DSs به جواب‌هایی نیاز دارند که در آن‌ها باید یک ویژگی سراسری تشخیص داده شود. • بحث Global Predicate Evaluation (GPE) مطرح می‌شود که در آن یک عبارت بولین بر حسب متغیرهایی که ارجاع به حالت سراسری سیستم دارند بیان می‌شود. • مشکل در بیان درستی این عبارات بولین وجود عدم قطعیت در DSs به خاطر تاخیر ارتباطی و سرعت نسبی محاسبات و... استدلال با اطلاعات ناقص و گاهاً نامشخص! حالات سراسری سازگار در DSs

  3. حالت سراسری یک DSs اتحاد حالات همه پردازه‌های منفرد است، معهذا در ارتباط پردازه‌ها از طریق مبادله پیغام، هر پردازنده باید اجزاء Remote را هم در حالت خود دخیل بداند. در نتیجه باید به گونه‌ای عمل شود که حالت سراسری با معنی باشد. • نکته اصلی این که، حالت سراسری که توسط هر پردازه مشاهده یا ثبت می‌شود یک حالت سراسری کامل و سازگار نیست! دلیل اصلی تاخیر مبادلات و اختلاف سرعت پردازشی اجزاء مختلف سیستم است. • هر پردازه دارای یک دید محلیاز حالات سراسری سیستم دارد که الزاماً با دید دیگران یکی نیست. • با افزایش فرکانس ارتباط بین پردازه‌ها این دید محلی به واقعیت نزدیک‌تر می‌شود ولی برای تضمین سازگاری حالت سراسری کافی نیست!!! مقدمه

  4. برای تضمین سازگاری یک حالت سراسری ساخته شده باید درباره دو مورد زیر استدلال کنیم: • ترتیب مشاهده پیغام‌ها بوسیله یک پردازه: به نحوی نشان دهیم که همه پیغام ها را با ترتیب یکسانی می بینند! • محتوای پیغام‌های مبادله شونده توسط پردازنده. • در این بخش، GPE به شکل رسمی (Formal) بیان می‌شود که هدف از آن تشخیص این است که آیا حالت سراسری، گزاره مشخصی مثل  را متقاعد می‌کند یا نه؟ گزاره ‌های سراسری برای کد کردن ویژگی‌های مورد علاقه ما از DS بر حسب متغیرهای حالت بیان می‌شوند. • نمونه‌هایی از این مسایل در DSs شامل تشخیص بن بست، تشخیص اختتام، تشخیص گم شدن مهره، زباله روبی (حافظه غیر قابل دسترس)، نقطه مقابله و بازآغازی، Debug و... مقدمه - ادامه

  5. یک DS مجموعه‌ای پردازه‌های ترتيبی (P1,P2,…,Pn) و یک شبکه است که قابلیت پیاده‌سازی کانال‌های ارتباطی یک طرفه را بین هر زوج پردازه داشته باشد. • فرض: • کانال‌ها مطمئن هستند ولی ممکن است پیغام‌ها را نامرتب مبادله کنند. (Out of Order) • شبکه ارتباطی کاملا مرتبط است. (Fully Connected) سیستم های توزیع شده ناهمگام A.D.Ss

  6. در تعریف ویژگی‌های یک DS، سعی خواهیم کرد که ضعیف‌ترین مجموعه فرض‌ها را داشته باشیم تا سقف بالای هزینه را در حل مسایل داشته باشیم. یعنی اگر راه حلی برای یک مساله DS در این مدل با هزینه  وجود داشته باشد، در مورد مساله‌ای مشابه راه حلی وجود خواهد داشت با هزینه کمتر از  (در هر DS). • ضعیف ترین مدل ممکن همانا ناهمگانی سیستماست یعنی: • محدودیتی در سرعت‌های نسبی پردازه‌ها وجود ندارد (No Bound) . • محدودیتی در تاخیر پیغام‌ها وجود ندارد. • امکان نگهداری ساعت‌های همگام از بین می‌رود و یا امکان استدلال برمبنای ساعت واقعی از بین می‌رود. از طرف دیگر ADS برای سیستم‌های واقعی موجود واقع بینانه‌تر است. سیستم های توزیع شده ناهمگام A.D.Ss - ادامه

  7. غیر رسمی، یک محاسبات توزیع شده اجرای یک برنامه توزیع شده به وسیله مجموعه‌ای از پردازه‌ها را شرح می دهد. • فعالیت هر پردازه به عنوان اجرای دنباله‌ای از وقایع مدل می‌شود. • انواع وقایع: • داخلی: در نتیجه تغییر حالت داخلی پردازه • تبادل پیغام با یک پردازه دیگر .... فرض ما در این مورد عبارت است از: • Send(m): m را در صف خروجی می گذارد. • Receive(m): m را از صف بر می دارد. (برای رخداد Receive(m) در پردازه P، باید P بخواهد که دریافت کند و m به P رسیده باشد.) محاسبات توزیع شده

  8. تعریف: سابقه محلی Pi در طی محاسبه دنباله‌ای (احتمالا نامحدود) از وقایع است: hi = ei1 ei2 ei3 … • اگر hik = ei1 ei2 … eik یک پیشوند اولیه از سابقه محلی Pi (شامل k واقعه اولیه) باشد، hi را یک دنباله تهی تعریف می‌کنیم. • سابقه سراسری یک محاسبه توزیع شده مجموعه‌ای شامل همه سوابق محلی است: H= h1 h2 h3 … hn • در سابقه سراسری هیچ ترتیب زمانی بین همه وقایع نداریم. محاسبات توزیع شده - ادامه

  9. در ADS وقایع محاسباتی تنها بر اساس رابطه "علت و معلولی" می‌توانند مرتب شوند، یعنی رخداد اولی باعث رخداد دومی باشد. • دو دلیل برای این رابطه: • دو واقعه از یک پردازه که بر اساس زمان محلی پشت سرهم اجرا شده اند روی هم اثر می‌گذارند. • دو واقعه که مربوط به پردازه‌های متفاوت ولی مربوط به تبادل یک پیغام هستند نیز روی هم اثر می‌گذارند. محاسبات توزیع شده - ادامه

  10. رسمی کردن این ایده‌ها با تعریف رابطه  روی وقایع: If eik, eil  hi and k<l Then eik eil If ei = Send(m) and ej = Receive(m) Then ei ej If e  e’ and e’  e’’ Then e  e’’ نتیجه‌ای که از ee' می‌توان گرفت این است که رخداد e' و نتایجش ممکن است متاثر از eباشد. e||e' وقتی که و . صوری: یک محاسبه توزیع شده یک Poset (مجموعه ترتیب جزیی (H, ) است که معادل آن می توان یک نمودار Time Space نیز داشت. محاسبات توزیع شده - ادامه

  11. محاسبات توزیع شده - ادامه e14 e15 e11 e12 e13 e16 P1 resp req req req e22 P2 e21 e23 resp req P3 e32 e31 e33 e34 e35 e36 C C

  12. اگر ik حالت محلی پردازنده Pi بلافاصله پس از اجرای واقعه ikباشد و i حالت اولیه Pi باشد، حالت سراسری یک محاسبه توزیع شده چند تایی  = (1, … , n) از حالات محلی است. • یک برش(Cut) از یک محاسبه توزیع شده یک زیر مجموعه C از یک سابقه سراسری H است و شامل پیشوند اولیه هر یک از سوابق محلی است. • چنین برشی را C = h1C1 h2C2… hnCn)) با چندتایی اعداد طبیعی (C1,…,Cn) متناظر با اندیس آخرین واقعه موجود در برش می‌توان نشان داد. • مجموعه آخرین وقایع (e1C1, e2C2,…, enCn) در برش C را حد فاصل (مرز) آن برش گویند. (Frontier) • متناظر با هر برش مثل (C1,…,Cn) یک حالت سراسری متناظر (­1C1, ­2C2,…, nCn) وجود دارد. Global States, Cuts, Runs

  13. e14 e15 e11 e12 e13 e16 P1 resp req req req e22 P2 e21 e23 resp req P3 e32 e31 e33 e34 e35 e36 مثال در شکل زیر برش های C متناظر با چندتایی (5,2,4) و برش C' متناظر با (3,2,6) است. C C

  14. توجه کنید که در واقعیت، وقایع یک سیستم توزیع شده می توانند در یک ترتیب کلی جای بگیرند!! تعریف Run: یک اجرا یا Run از یک محاسبه توزیع شده (D.C.)، یک ترتیب کلی R است که شامل همه وقایع سابقه سراسری باشد و با سوابق محلی نیز سازگار باشد. (در واقع به ترتیب وقایع محلی احترام گذارد.) Global States, Cuts, Runs

  15. GPE می‌تواند بوسیله ارزیابی یک Predicate () بیان شود که تابعی است از حالت سراسری . از این به بعد فرض می‌کنیم یک پردازه مبصر P0 داریم که یکی از P1,…,Pn و یا جدای از این مجموعه است. • برای بدست آوردن حالت‌سراسری، مبصر پیغام State Enquiry می‌فرستد و هر پردازه با دریافت پیغام، حالت محلی i خود را بر می‌گرداند. با رسیدن پاسخ، حالت سراسری (1, 2,…, n) ایجاد می شود. • فرض می‌کنیم تعامل P0 اثری در حالت سیستم ندارد. (برای سادگی) Monitoring Distributed Computing

  16. ترتیب علـّی روش مناسبی برای تمایز دو دسته از برش هاست، یک برش C سازگار نامیده می‌شود اگر برای همه وقایع e و e' داشته باشیم: • در نمودار گرافیکی، کافی است همه پیکان‌ها از برش خارج شده باشند تا برش سازگار باشند. • یک حالت سراسری سازگار آن است که متناظر با یک برش سازگار باشد. • توجه: برش‌های سازگار یک عنصر مبنایی در فهم ADS است. مثل زمان عددی در سیستم‌های پی‌در‌پی که لحظه مشخصی از پردازش را مشخص می‌کنند، حد فاصل (مرز) یک برش سازگار معرف یک لحظه "Instant" در یک DC است. • Before وAfter معنا پیدا می‌کند. (قبل یا بعد از برش بودن) سازگاری

  17. مقادیر یک Predicate وقتی معنا پیدا می‌کند که در حالات سراسری سازگار ارزیابی شوند چرا که حالاتی هستند که در یک اجرا می‌توانند معنی داشته باشند. • اجرای R را سازگار گوییم (Consistent Run) اگر برای همه وقایع، از ee' نتیجه بگیریم که e قبل از e' در R ظاهر شده است. یعنی احترام به ترتیب تعریف شده در ترتیب علـّی. • نتیجه اجرای R=e1e2e3…، دنباله 012… از حالات سراسری است که 0 حالت سراسری اولیه (10, 20,…, n0) است. اگر اجرا سازگار باشد حالات سراسری در دنباله نیز سازگار هستند. • توجه: Run هم دنباله وقایع و هم به دنباله‌ای از حالات سراسری نتیجه شده اطلاق می‌شود. سازگاری - ادامه

  18. هر حالت سراسری (سازگار) i از یک اجرا از حالت قبلی i-1 بدست آمده که یک پردازه واقعه ei را اجرا کرده است. برای دو حالت سراسری سازگار در R (مثل بالا) گوییم i-1 در R منجر می‌شود بهi. اگر بستار تعددی رابطه منجر شدن در R باشد، گوییم ' قابل دسترس از  است. (در R)، اگگر: مجموعه همه حالات سراسری سازگار از یک D.C. با رابطهمنجر ‌شدن(leads-to) یک شبکه (Lattice) را تعریف می‌کند که شامل n تا محور Orthogonal (هر محور برای یک پردازه) است. سازگاری - ادامه

  19. اگر K1…Kn خلاصه (کوته نوشتی) برای حالت سراسری (1K1, 2K2,…, nKn) و K1K2…Knسطح آن باشد شکل زیر یک D.C. با دوپردازه و شبکه متناظر آن را نشان می‌دهد. 00 حالت سراسری اولیه است. یک مسیر در شبکه دنباله‌ای از حالات سراسری با افزایش سطح است (به سمت پایین) طوری که سطح بین هر دو جزء یکی تفاوت داشته باشد. هر مسیر در شبکه متناظر با یک اجرای سازگار (Cons. Run)است و می‌گوییم اجرا از حالات سراسری درون مسیر رد شده است. سازگاری - ادامه

  20. مثال: یک اجرای ممکن می‌تواند از دنباله حالات سراسری زیر رد شود: 000111213132424344546565 مثال 00 1001 1102 21 12 03 31 22 1314 41 32 2314 42 33 24 43 34 53 44 35 63 54 45 64 55 65 e14 e15 e11 e12 e13 e16 P1 P2 e21 e23 e24 e25 e22

  21. یک راه دیگر برای پردازه مبصر P0 این است که P0 حالت منفعل داشته باشد. یعنی هرگاه کاربردی واقعی را اجرا کرد با ارسال پیغامی به P­0 آن‌را اعلام کند. البته باید توجه داشته باشید که مکانیزم کنترل توسط P0 شامل وقایع جدید حاصل از مبادله پیغام‌های کنترلی در حالت سیستم منظور نمی‌شود.  مشاهده‌ای از D.C. معادل ترتیب آمدن اعلانات از پردازه‌هاست. • نکته: به لحاظ متغیر بودن تاخیر اعلانات (به P0)، ‌اجرای واحدی از یک D.C. می‌تواند مشاهدات مختلفی را در مبصرهای متفاوت داشته باشد. (پدیده یا اثر نسبیت Relativistic) • نکته: یک مشاهده می‌تواند متناظر با یک اجرای سازگار، ‌یک اجرای ناسازگار و یا هیچ اجرایی باشد؛ چرا که وقایع یک پردازه ممکن است با ترتیب مختلفی از ترتیب موجود در سابقه محلی‌اش دیده شود. • مشاهده سازگار آن است که متناظر با یک اجرای سازگار باشد. مشاهده محاسبات توزیع شده

  22. مثال: اجرای سازگار زیر را با استفاده از شکل، مشاهده کنید: R = e31 e11 e32 e21 e33 e34 e22 e12 e35 e13 e14 e15 e36 e23 e16 مشاهدات سه‌گانه زیر از R ممکن است: O1: e21 e11 e31 e32 e34 e12 e22 e33 e13 e34 e35 … O1 متناظر با اجرا نیست زیرا e34قبل از e33 آمده است. O2: e11 e31 e21 e32 e12 e33 e34 e13 e22 e35 e36 … O2 متناظر با اجرای ناسازگار است. معادل با C' در شکل قبل است. O3: e31 e21 e11 e12 e32 e33 e13 e34 e14 e22 e15 … O3‌ معادل با C در شکل قبل است. توجه: چون کانال ویژگی Out of Order را دارد، هر ترتیبی از R می‌تواند مشاهده شود. هرچند بعضی بی‌معنی می‌شوند! مثال

  23. می‌توان ترتیب پیغام‌های بین دو پردازه را با تعریف قاعده حمل (تحویل) برای تشخیص این‌که چه موقع پیغام‌های رسیده به‌کاربرد ارائه شود، اعمال کرد. در نتیجه جهت اعلام آمادگی کاربرد برای گرفتن پیغام، به جای Receive از Deliver استفاده می‌کنیم. • گوییم که ارتباط از Pi به Pj حمل FIFO را مراعات می‌کنند اگر برای هر m و m' داشته باشیم: FIFO Delivery: Sendi(m)Sendi(m') Deliverj(m)Deliverj(m') • این قاعده تضمین می‌کند که مشاهدات متناظر با اجراها باشد ولی نه الزاما اجراهای سازگار. • در نتیجه به دنبال قاعده‌ای هستیم تا تناظر بین مشاهدات و اجراهای سازگار را تضمین کند. مشاهده محاسبات توزیع شده - ادامه

  24. فرض کنید همه پردازه‌ها به یک ساعت سراسری دسترسی دارند و تاخیر پیغام‌ها به  محدود است. RC(e) مقدار زمان سراسری در لحظه رخداد e است. در نتیجه در اعلان واقعه به P0 (مبصر)، RC(e) نیز ضمیمه می‌شود. قاعده حمل P0 چنین خواهد بود: • DR1: در لحظه t،‌ همه پیغام‌های رسیده با زمان‌مهر تا t- را به ترتیب صعودی زمان‌مهر تحویل بگیر. حال مشاهدات P0 با اجرای سازگار متناظر است! Clock Condition: e  e'  RC(e) < RC(e') مشاهده محاسبات توزیع شده - ادامه

  25. در نبود ساعت واقعی، می‌توان با یک ساعت منطقی که سازگاری با ترتیب علّی را تضمین کند، مسایل مربوط به ADS را حل کرد. برای خیلی از کاربرد‌ها همین ساعت منطقی کفایت می‌کند. • روش کار: • هر پردازه یک ساعت (LC) دارد که یک شمارنده اعداد طبیعی به جلو است. • LC: مقدار فعلی ساعت محلی • LC(ei): مقدار ساعت محلی در لحظه رخداد ei • هر پیغام ممهور به ساعت منطقی محلی فرستنده است. • نحوه به‌روز درآوری LC عبارتست از: • توجه کنید اگر e  e' سپس LC(e) < LC(e'). در نتیجه طبق بحث قبلی مشاهدات ما سازگار خواهند بود. ساعت‌های منطقی

  26. اگر یک قاعده تحویل که در آن پیغام‌ها به ترتیب زمان‌مهرشان (صعودی) تحویل می‌شوند را در نظر بگیریم و در موارد همروندی هم از اندیس پردازه استفاده کنیم،‌ پردازه ناظر در شکل زیر مشاهده زیر را خواهد ساخت: • e11 e21 e31 e12 e32 e33 e13 e34 e14 e22 e35 e15 e23 e16 e36 • سازگار است. • اعداد ساعت منطقی محلی است. ساعت‌های منطقی - ادامه P1 5 6 7 1 2 4 P2 5 1 6 P3 2 3 4 5 1 7

  27. ولی قاعده فوق (DR1) خاصیت Liveness را ندارد! بدون محدودیت روی تاخیر پیامی، هیچ پیغامی دریافت نمی‌شود، چراکه بیم رسیدن پیغام با زمان‌مهر کوچک‌تر وجود دارد. این موضوع به دلیل فقدان خاصیت Gap Detection به وجود آمده است. تشخیص Gap(Gap Detection): دو واقعه e و e' را در نظر بگیرید که LC(e) < LC(e’) ، وجود Gap یعنی اینکه مشخص کنید که آیا واقعه دیگری مانند e'' وجود داشته باشد که: LC(e) < LC(e'') < LC(e') پیغام m رسیده به P پایا (Stable) تلقی می‌شود، ‌اگر پیغام دیگری با زمان‌مهر کوچکتر به P نرسد. DR2: همه پیغام‌های پایای رسیده به P0 را به ترتیب صعودی زمان‌مهر دریافت کن (تحویل بگیر). ساعت‌های منطقی - ادامه

  28. حمل FIFO تضمین می‌کرد که پیغام‌های صادره به‌وسیله یک پردازه به ترتیب تحویل می‌شوند. می‌توان این ایده را تعمیم داد که محدود شود به پیغام‌هایی که علّا به هم مربوط هستند. اگر چه به‌وسیله پردازه‌های مختلفی ارسال شده باشند. Casual Delivery (CD): Sendi(m) Sendj(m')  Deliverk(m) Deliverk(m') (For all m, m' and sending processes Pi , Pj and receiving process Pk) سیستمی که به CD احترام می‌گذارد،‌ نمی‌توان درباره وجود پیغامی قبل از رخداد تحویل یک پیغام ادعا کرد. وجود حمل FIFO بین همه زوج پردازه‌ها،‌CD را تضمین نمی‌کند. در مورد مشاهدات مبصر (P0): اگر P0 قاعده حمل CD را رعایت کند،‌ همه مشاهداتش سازگار خواهد بود. حمل علّی (Casual Delivery) P1 P2 m m' P3

  29. برای پیاده‌سازی کارآی حمل علّی، به یک رویه کارآ برای تشخیص مورد زیر لازم داریم: • با داشتن دو واقعه e و e' (که علّا به هم مربوط هستند) و ساعت‌های متناظشان، آیا واقعه دیگری مثل e'' وجود دارد که: e  e''  e' • با حمل پیغام‌های اعلان (به P0) در ترتیب صعودی زمان‌مهر،‌ قواعد DR1 و DR2 فرض می‌کنند که RC(e) < RC(e') (یا LC(e) < LC(e')) دلالت می‌کند بر e  e'. ولی زمان‌مهر‌های تولید شده به‌وسیله ساعت واقعی یا منطقی تنها شرط ساعت را تضمین می‌کنند که معکوس عبارت بالاست. یعنی الزامی نیست که وجود رابطه < بین دو ساعت مربوط به e و e' منجر به رابطه علّی e  e' شود. (زیرا ممکن است که e || e') • با رسیدن اعلان واقعه e'، DR1 و DR2 می‌تواند (غیر ضرور) تحویل آن‌را به تاخیر بیاندازند، هر چند بتواند همه زمان‌مهرهایی که باید برسند را هم تشخیص دهند. این تاخیر غیر ضروری است اگر اعلانات بعدی که زمان‌مهر کوچکتری دارند مربوط به وقایع همروند e' باشند! ایجاد رابطه ترتیب علّی

  30. پیشنهاد مکانیزم TC که از زمان‌مهرهای آن رابطه علّی بین وقایع استنتاج می‌شود. Strong Clock Condition: e  e'  TC(e) < TC(e') (Clock Condition: e  e'  RC(e) < RC(e') یادآوری:) هر چند ساعت‌های واقعی (Real Time) و منطقی با ترتیب علّی سازگار است، ‌مکانیزم زمانی TC ترتیب علّی را مشخص می‌کند. چرا که همه محاسبات می‌تواند از یک مشاهده منفرد شامل TC (به عنوان زمان‌مهر) بازسازی شوند. از این امکان نه تنها برای پیاده‌سازی کارآی CD استفاده می‌شود،‌ بلکه برای کاربردهای دیگری نظیر Distributed Debug و .. نیز استفاده می‌شود. ایجاد رابطه ترتیب علّی

  31. سوابق علّی: مقدمه‌ای برای تعیین نحوه پیاده‌سازی TC سابقه علّی واقعه e در محاسبه توزیع شده‌ی (H,) عبارتست از: یا: کوچکترین برش سازگار که شامل e باشد. تصویر (e) روی پردازه Pi عبارتست از: سوابق علّی

  32. سابقه علّی واقعه e14: (e14) = (e11, e12, e13, e14, e21, e31, e32, e33) مثال e14 e15 e11 e12 e13 e16 P1 resp req req e22 req P2 e21 e23 resp req P3 e32 e31 e33 e34 e35 e36

  33. نگهداری سوابق علّی ساده است، کافی است هر پردازه Pi متغیر محلی  را مساوی تهی قرار دهد و سپس • اگر ei دریافت m به‌وسیله Pi (از Pj) باشد، سپس (ei) از اتحاد ei،‌ سابقه علّی واقعه محلی قبلی Pi و سابقه علّی واقعه ارسال متناظر با ei (که در زمان‌مهر m وجود دارد) بدست می‌آید. • اگر ei واقعه داخلی یا ارسال باشد، (ei) از اتحاد ei و سابقه علّی آخرین واقعه محلی قبلی بدست می‌آید. • اگر سابقه علّی به‌عنوان ساعت در نظر گرفته شود و مقایسه ساعت‌ها را به‌عنوان زیرمجموعه بودن بپذیریم، شرط قوی ساعت برآورده می‌شود: e  e' (e) (e') • مشکل سوابق علی در رشد زیاد آن‌هاست و لذا به عنوان ساعت نمی‌توان آن‌ها را به‌کار برد. سوابق علّی - ادامه

  34. می‌توان سوابق علّی را مرتب کوتاه نمود تا مناسب برای ساعت باشند. یعنی بخشی از سوابق که برای همه وقایع مشترک است، حذف شوند. بنابراین سابقه علّی می‌تواند با یک آرایه ثابت (اندازه بعد‌ها) ارائه شود. • توجه: • تصویر (e) روی پردازه Pi همانا یک پیشوند از سابقه محلی Pi است. i(e) = hik for some k and eili(e) for all l<k • بنابراین یک عدد طبیعی کافی است تا مجموعه i(e) را نشان دهد. • چون (e)= 1(e) 2(e)  … n(e) پس کل سابقه علّی می‌تواند با یک بردار n بعدی از اعداد طبیعی نشان داده شود: VC(e) (یعنی بردار ساعت e) طوری که برای همه 1  i  n داریم: VC(e)[i] = K , iff i(e) = hiK • بنابراین هر پردازه Pi یک بردار محلی از اعداد طبیعی (VC) نگهمیدارد که VC(ei) معروف به ساعت بردار Pi وقتی که ei­ را اجرا کرده است،‌ می‌باشد. • هر پیغام m شامل یک زمان‌مهر TS(m) است که مقدار بردار ساعت واقعه ارسال m است. ساعت بردارها

  35. قواعد بردار ساعت عبارتنداز: VC(ei)[i] := VC[i] + 1 if ei is a send or an internal event. VC(ei) := max {VC, TS(m)} if ei = receive (m) VC(ei)[i] := VC[i] + 1 تفسیر ما از j امین عنصر بردار ساعت پردازه Pi: (به ازای همه j : ij) VC(ei)[j] := # of events of Pj that causally precede event ei of Pi VC(ei)[i] معرف تعداد وقایعی از Pi است که تا ei (و شامل ei) اجرا شده‌اند. تعریف رابطه < بین دو بردار ساعت: ساعت بردارها - ادامه

  36. خاصیت ۱: Strong Clock Condition e  e'  VC(e) < VC(e') خاصیت ۲: Simple Strong Clock Condition: اگر ei از Pi و ej از Pj را در نظر بگیریم که ij باشد: eiej VC(ei)[i]  VC(ej)[i] VC(ei)[i]  VC(ej)[i] ممکن است و نشان می‌دهد که ei آخرین واقعه Pi بوده است که علاّ قبل از ej رخ داده است. (برای مثال ارسال یک پیغام به Pj بوده است) از خاصیت زیر برای تست‌ همروندی وقایع استفاده می‌کنیم. خاصیت ۳: (همروندی): با فرض ei از Pi و ej از Pjداریم: خواص بردار ساعت

  37. خاصیت ۴: ناسازگاری زوجی: ei از Pi زوجا با ej از Pj ناسازگار است (ij) اگگر: • از این خاصیت برای کنترل سازگاری برش‌ها استفاده می‌کنیم. ei و ej ناسازگارند اگر نتوانند به حد فاصل یک برش سازگار تعلق داشته باشند. • دو بخش این عبارت دو حالتی را که احتمال دارد یک برش دریافتی را داشته باشد که ارسال آن ثبت نشده است را نشان می‌دهد. • خاصیت ۵: (برش سازگار): یک برش (C1,…,Cn) سازگار است اگگر: • توجه: VC(ei)[j] معرف تعداد وقایع Pj است که علا قبل از ei از Pj هستند و VC(ei)[i] هم معرف تعداد وقایع اجرا شده در Pi (تا و شامل ei)،‌در نتیجه خواهیم داشت: • یعنی #(ei) تعداد وقایع علا قبل از ei در کل محاسبه است. خواص بردار ساعت - ادامه 

  38. خاصیت ۶: (شمارش): اگر ei از Pi باشد،‌تعداد وقایع e که e eiاست (VC(e) < VC(ei))،‌ عبارتست از #(ei) بردار ساعت‌ها فرم ضعیفی از خاصیت Gap Detection را ارائه می‌دهد که ساعت‌های منطقی و واقعی ارائه نمی‌کردند. خاصیت ۷: (Weak Gap Detection): اگر ei از Pi و ej از Pj باشد،‌ اگر برای هر k ای که kj است، داشته باشیم: پس واقعه‌ی ek وجود دارد که:  (ekei)  (ekej) ضعیف بودنش به خاطر این است که نمی‌توان نتیجه گرفت که یک زنجیر علّی داریم eiekej. البته اگر i = k باشد این نتیجه را می‌توان گرفت. خواص بردار ساعت - ادامه

  39. از خاصیت ۷ (Weak Gap Detection) می‌توان استفاده کرد تا حمل علّی را با بردار ساعت پیاده‌سازی کرد. فرض کنیم که پردازه‌ها جزء محلی خود از بردار ساعت‌ها را برای پیامی که به مبصر اطلاع می‌دهند،‌ افزایش دهند.  هر پیغام m یک TS(m) را حمل می‌کند که بردار ساعت واقعه‌ای است که به‌وسیله m اعلام می‌شود. • فرض کنیم که همه پیغام‌های رسیده به P0 ولی تحویل نشده در M نگهداری شوند. mM از Pj را قابل تحویل می‌دانیم هرگاه P0 بتواند مطمئن شود که پیغام دیگری وجود ندارد (نه در M و نه در راه)، که ارسالش علاّ قبل از m باشد. پیاده‌سازی حمل علی با بردار ساعت

  40. اگر m' آخرین پیغام تحویل شده از Pk باشد،‌ قبل از تحویل mاز Pj، P0 باید دو شرط زیر را کنترل کند (kj): • پیغام دیگری از Pj وجود ندارد که تحویل نشده باشد. اگر TS(m)[j]-1 تا پیغام قبلا از Pj تحویل شده باشد،‌ این شرط برقرار است. • پیغام تحویل نشده‌ی m''يی وجود ندارد (از Pk) که: Send(m')  Send(m'')  Send(m) , kj می‌توان حالت خاصی از W.G.D را استفاده کرد که: i = k و ek = Sendk(m'') و ei = Sendk(m') و ej = Sendj(m). چون ei و ek هر دو در Pk رخ داده اند،‌ می‌توان از خاصیت ۷ استفاده کرد: و اگر برای kیی (kj) داشته باشیم:‌ TS(m')[k] < TS(m)[k] سپس واقعه‌ی Sendk(m'')یی وجود دارد که: Sendk(m') Sendk(m'') Sendj(m) • اگر TS(m')[k]  TS(m)[k] باشد،‌ هیچ پیغام تحویل نشده (حمل نشده) m''یی وجود نخواهد داشت. (k) پیاده‌سازی حمل علی با بردار ساعت - ادامه

  41. اگر P0 یک آرایه D[1…n] از شمارنده‌ها (ابتدا صفر) را نگهدارد که D[i]=TS(mi)[i] و mi آخرین پیغام حمل شده از Pi باشد،‌قاعده حمل می‌تواند چنین باشد: • DR3: (حمل علّی): پیغام m را از Pj به مجرد مهیا شدن دو شرط زیر حمل کن: • D[j] = TS(m)[j]-1 • D[k]  TS(m)[k] , kj • وقتی P0، m را حمل می‌کند (تحویل می‌گیرد)، D به‌روز در می‌آید. • D[j] = TS(m)[j]. پیاده‌سازی حمل علی با بردار ساعت - ادامه

  42. شکل زیر کاربرد این حمل به‌وسیله P0 را در یک محاسبه ساده نشان می‌دهد. در P1 و P2 مقادیر بردار ساعت است ولی در P0 مقادیر بردار D را داریم. تحویل m’ به تاخیر افتاده است تا m برسد و تحویل شود. m’’ به محض رسیدن تحویل می‌شود. حمل (تحویل) علّی می‌تواند در مورد هر پردازه‌ای به جز مبصر P0 اعمال شود. Casual Broadcast روش مناسبی برای تحویل علّی است که در ساخت کاربرد‌های توزیع شده به‌کار می‌رود. پیاده‌سازی حمل علی با بردار ساعت - مثال P0 [0,0] [1,1] [1,0] [2,1] m m [0,0] [1,0] P1 [1,1] [2,1] m [0,0] P2 [1,0] [1,1]

More Related