سؤال

ما مدى تشابه الحوسبة الموزعة والخيوط؟ لقد وجدت ورقتين تتوصلان إلى استنتاجات معاكسة تمامًا:

"متعدد الخيوط أسهل من الشبكات. كيف يكون الترابط سهلًا ومشابهًا لرمز الشبكة"

http://software.intel.com/file/14723

(هذا يعطيني انطباعًا بأنهم متشابهان للغاية لدرجة أنه بعد التغليف ، يمكن القيام هذين النهجين بنفس الرمز - لكن ربما أكون مخطئًا)

"ملاحظة على الحوسبة الموزعة"

http://research.sun.com/techrep/1994/abstract-29.html

(وهذا يضع تمييزًا قويًا)

أنا متأكد من أن الحقيقة في مكان ما بينهما. ماذا هو يعني الذهبي؟ هل هناك أي تقنيات توحيد هذين النموذجين؟ أو هل فشلت مثل هذه المحاولات بسبب الاختلافات الأساسية بين الشبكات والتزامن؟

هل كانت مفيدة؟

المحلول

لم أجدهم متشابهين جدًا. اسمحوا لي أن أعرّف لأغراض هذا المنشور "عقدة" لتكون مؤشر ترابط أجهزة واحد يعمل على جهاز واحد. لذا فإن الجهاز الأساسي الرباعي هو أربع عقد ، وكذلك مجموعة من أربعة صناديق معالج واحد.

عادةً ما تقوم كل عقدة بتشغيل بعض المعالجة ، وسوف يكون هناك نوع من التواصل عبر العقدة. عادة ما تكون الحالة الأولى لهذا الاتصال هي إخبار العقدة بما يجب القيام به. بالنسبة لهذا الاتصال ، يمكنني استخدام الذاكرة المشتركة ، والرملة ، والملفات المشتركة ، والأنابيب المسمى ، والمآخذ ، ومكالمات الإجراءات عن بُعد ، وتوزيعها ، وما إلى ذلك ، لكن الأسهل لاستخدام الذاكرة المشتركة والرماة ، لا تتوفر عادة عبر شبكة. قد تتوفر الملفات المشتركة ، لكن الأداء عادة ما يكون ضعيفًا. تميل المقابس إلى أن تكون الخيار الأكثر شيوعًا والأكثر مرونة على الشبكة ، بدلاً من الآليات الأكثر تطوراً. في هذه المرحلة ، يجب عليك التعامل مع تفاصيل بنية الشبكة ، بما في ذلك الكمون وعرض النطاق الترددي وفقدان الحزم وطوبولوجيا الشبكة والمزيد.

إذا بدأت بقائمة انتظار من العمل ، فيمكن للعقد على نفس الجهاز استخدام ذاكرة مشتركة بسيطة للحصول على أشياء للقيام بها. يمكنك حتى كتابته بدون قفل وسوف يعمل بسلاسة. مع العقد عبر الشبكة ، أين تضع قائمة الانتظار؟ إذا قمت بتركيزها ، فقد تعاني هذا الماكينة من تكاليف عرض النطاق الترددي المرتفعة للغاية. حاول توزيعها وأصبحت الأمور معقدة للغاية بسرعة كبيرة.

ما وجدته ، بشكل عام ، هو أن الأشخاص الذين يتناولون هذا النوع من الهندسة المعمارية المتوازية يميلون إلى اختيار المشكلات المتوازية بشكل محرج لحلها. Raytracing يتبادر إلى الذهن. لا يوجد الكثير من التواصل عبر العقدة المطلوبة ، بصرف النظر عن توزيع الوظائف. هناك العديد من المشكلات مثل هذا ، بالتأكيد ، لكنني أجد أنه من المخادع بعض الشيء الإشارة إلى أن الحوسبة الموزعة هي نفسها في الأساس مثل الخيوط.

الآن إذا كنت ستذهب إلى كتابة الخيوط التي تتصرف بشكل متماثل لنظام موزع ، باستخدام تمرير الرسائل الخالصة وعدم افتراض أن أي مؤشر ترابط هو "الرئيسي" وما شابه ، نعم ، سيكونون متشابهين للغاية. ولكن ما فعلته هو التظاهر بأن لديك بنية موزعة ونفذها في المواضيع. الشيء هو أن الخيط هو حالة أبسط بكثير من التوازي من الحوسبة الموزعة الحقيقية. يمكنك تجريد الاثنين في مشكلة واحدة ، ولكن عن طريق اختيار الإصدار الأصعب والالتزام به بدقة. ولن تكون النتائج جيدة كما يمكن أن تكون عندما تكون جميع العقد محلية في الجهاز. أنت لا تستفيد من الحالة الخاصة.

نصائح أخرى

يتم توزيع الحوسبة على أجهزة مستقلة مختلفة متعددة ، بشكل عام مع نظام التشغيل المتخصص في بعض الأحيان. يكون الأمر أكثر صعوبة لأن الترابط بين الآلات أقل بكثير ، وبالتالي يصعب حل المشكلات التي تتطلب الكثير من الوصول العشوائي السريع إلى مجموعة البيانات بأكملها.

بشكل عام ، تحتاج إلى مكتبات متخصصة للقيام بمشكلات الحوسبة الموزعة التي تكتشف كيفية تعيين العقد للمشاكل والاقتران حول البيانات.

أتساءل حقًا عما إذا كانوا يواجهون استنتاجات مختلفة لأنهم يحاولون حل المشكلات الخاطئة على كل منصة. تلتزم بعض المشكلات بشكل جيد للغاية بالآلات المترابطة للغاية ، ويمكن أن تستفيد من أجهزة الكمبيوتر العملاقة حقًا. يمكن التعامل مع المشكلات الأخرى على النماذج الموزعة ببساطة. بشكل عام ، يمكن لأجهزة الكمبيوتر العملاقة حل مجموعة واسعة من المشكلات ، ولكنهم أكثر تخصصًا وأكثر تكلفة بكثير.

يبدو أن الفرق يعود إلى خيوط مشاركة الحالة ، وعمليات تمرير الرسائل.

تحتاج إلى أن تقرر كيف تريد الحفاظ على الحالة في تطبيقك قبل اختيار واحدة.

من السهل البدء في حالة المشاركة ، وجميع البيانات والمتغيرات موجودة فقط. ولكن بمجرد دخول ظروف الجمود/السباق ، من الصعب تعديل/الحجم.

يتطلب مرور الرسائل (على سبيل المثال erlang) مقاربة مختلفة للتصميم ، عليك التفكير في فرص للتزامن من البداية ، ولكن حالة كل عملية موزعة معزولة ، مما يجعل مشاكل القفل/العرق أسهل في التعامل معها.

أعتقد أنه من المفيد للغاية مقارنة العمليات مع أساليب الحوسبة الموزعة أكثر من مقارنة الخيوط بها. توجد المواضيع داخل عملية واحدة وتشارك نفس البيانات ونفس الذاكرة. هذا غير ممكن على عدة آلات. من ناحية أخرى ، تحتوي العمليات على ذاكرتها الخاصة ، على الرغم من أنها تحتوي في بعض الحالات على نفس البيانات تمامًا مثل عملية أخرى (بعد شوكة () ، على سبيل المثال). هذا يمكن تحقيقه عبر الشبكة.

شيء يضيف وزنًا إضافيًا إلى هذا القياس هو حقيقة أن العديد من الأدوات المستخدمة في اتصال العمليات هي شفافة الشبكة. ومن الأمثلة الجيدة على ذلك هو Sockets Unix ، والتي تستخدم نفس الواجهة مثل مآخذ الشبكة (باستثناء رمز الاتصال).

نعم في تطوير الوقت ، فإن النهج متشابه جدًا ولكن استخدام كل منهما مختلف تمامًا. لا أوضح فكرتك ، اسمحوا لي أن أعرف إذا كنت مخطئًا: عند الحديث عن الحوسبة الموزعة ، فإننا نفترض أكثر من رمز معالجة الكمبيوتر أو الخادم في نفس التطبيق ، ولكن عندما نتحدث عن متعدد الخيوط. يتحدثون عن معالجة مؤشرات ترابط مختلفة للتطبيق في نفس الوقت في نفس الكمبيوتر. يمكنك التفكير كمثال على الحوسبة الموزعة ، في تطبيق واحد يصل إلى خدمة ويب موجودة في الإنترنت. هناك نوعان مختلفان يعملان في نفس التطبيق.

إذا كنت تريد مثالًا على متعدد الخيوط ، فما عليك سوى التفكير في تطبيق يحاول العثور على رقم رئيسي واحد. إذا لم تكن تستخدم متعدد الخيوط فيه ، فلن تتمكن من رؤية أو القيام بأي شيء آخر في التطبيق في الوقت الذي يحسب فيه الرقم الرئيسي التالي (يمكن أن يكون وقتًا أو أكثر) لأن التطبيق لا يستجيب بينما يعمل في الحساب.

يمكنك مزجها أيضًا: كمثال أكثر تعقيدًا ، يمكنك دائمًا استخدام متعدد الخيوط للوصول إلى خدمات الويب المختلفة في نفس الوقت من خلال التطبيق نفسه ، وهذا لجعل التطبيق الخاص بك يستجيب حتى لو لم يكن متصلاً عند أحد الخوادم.

أعتقد أنه لا يمكن مقارنة هاتين الوثيقتين بسهولة. وثيقة Intel هي نوع من المقدمة في الخيوط ، ويحاولون شرح ذلك من خلال إيجاد التشبيهات لحوسبة الشبكة ، وهو أمر غريب بعض الشيء ومضلل بالنسبة لي. لست متأكدًا من سبب اختيارهم طريقة لتقديم الخيوط ، وربما كانوا يهدفون إلى الأشخاص المطلعين على الشبكات ، والتي ربما تكون أكثر شهرة أو على الأقل معترف بها من الخيوط.

وثيقة صن ، من ناحية أخرى ، مقال جاد ، يصور جميع الصعوبات المتعلقة بالبرمجة الموزعة. كل ما يمكنني فعله هو تأكيد ما يقولون فيه.

في رأيي ، فإن التجريد الذي يحاول إخفاء حقيقة أن كائن ما هو بعيد ضار لأنه عادة ما يؤدي إلى أداء سيء للغاية. يجب أن يكون المبرمج على دراية ببعد كائن ليكون قادرًا على استدعائه بطريقة فعالة.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top