ماخ (النواة)

ماخ

المطور(ون)	ريتشارد رشيد أفي تيفانيان
الإصدار الأولي	1985 ؛ منذ 39 سنة ( 1985 )
إصدار مستقر	3.0 / 1994 ؛ منذ 30 عامًا ( 1994 )
منصة	IA-32 ، x86-64 ، MIPS ، ARM32 ، Aarch64 ، m88k
يكتب	النواة الدقيقة
موقع إلكتروني	مشروع ماخ

Mach ( / mɑːk / ) ^[1] هي نواة تم تطويرها في جامعة كارنيجي ميلون بواسطة ريتشارد رشيد وأفي تيفانيان لدعم أبحاث أنظمة التشغيل ، وخاصة الحوسبة الموزعة والمتوازية . غالبًا ما يُعتبر Mach أحد أقدم الأمثلة على النواة الدقيقة . ومع ذلك، ليست كل إصدارات Mach عبارة عن نوى دقيقة. مشتقات Mach هي أساس نواة نظام التشغيل في GNU Hurd ونواة XNU الخاصة بشركة Apple المستخدمة في macOS و iOS و iPadOS و tvOS و watchOS .

استمر المشروع في جامعة كارنيجي ميلون من عام 1985 إلى عام 1994، ^[2] وانتهى بإصدار Mach 3.0، وهو نواة دقيقة حقيقية . تم تطوير Mach كبديل للنواة في إصدار BSD من يونكس ، ولا يتطلب تصميم نظام تشغيل جديد حوله. يوجد Mach ومشتقاته داخل العديد من أنظمة التشغيل التجارية. يتضمن هذا استخدام نواة نظام التشغيل XNU التي تتضمن Mach غير الدقيقة السابقة كمكون رئيسي. تم اعتماد نظام إدارة الذاكرة الافتراضية Mach أيضًا في 4.4BSD من قبل مطوري BSD في CSRG ، ^[3] ويظهر في أنظمة يونكس الحديثة المشتقة من BSD مثل FreeBSD .

Mach هو الخليفة المنطقي لنواة Accent من Carnegie Mellon . يعمل ريتشارد رشيد، كبير مطوري Mach، في Microsoft منذ عام 1991؛ حيث أسس قسم Microsoft Research . كان المؤسس المشارك لمطور Mach، آفي تيفانيان، رئيسًا سابقًا للبرمجيات في NeXT ، ثم رئيس قسم تكنولوجيا البرمجيات في Apple Inc. حتى مارس 2006. ^{[4] [2]}

كان المطورون يركبون الدراجات لتناول الغداء عبر برك الطين الممطرة في بيتسبرغ، ومازح تيفانيان بأن كلمة "muck" يمكن أن تشكل اختصارًا خلفيًا لنواة الاتصالات متعددة المستخدمين (أو متعددة المعالجات العالمية). سأل مهندس CMU الإيطالي داريو جوزيه ^[5] لاحقًا قائد المشروع ريك رشيد عن العنوان الحالي للمشروع وتلقى "MUCK" كإجابة، على الرغم من عدم تهجئتها ولكن نطقها فقط IPA: [mʌk] . وفقًا للأبجدية الإيطالية ، كتب "Mach". أعجب رشيد بتهجئة جوزيه "Mach" كثيرًا لدرجة أنها سادت. ^{[6] : 103}

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

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

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

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

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

تم تنفيذ برنامج Aleph على أجهزة كمبيوتر صغيرة من نوع Data General Eclipse وكان مرتبطًا بها ارتباطًا وثيقًا. كان هذا الجهاز بعيدًا عن المثالية، حيث كان يتطلب نسخ الذاكرة بين البرامج، مما أدى إلى زيادة كبيرة في الأداء. كان مكلفًا للغاية أيضًا. ومع ذلك، أثبت برنامج Aleph أن النظام الأساسي سليم، واستمر في إثبات تجميع الكمبيوتر عن طريق نسخ الذاكرة عبر واجهة Ethernet المبكرة .

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

وقد تبنت جامعة كارنيجي ميلون هذا المفهوم، حيث قامت بتكييف نظام Aleph مع محطة عمل PERQ ونفذته باستخدام النسخ عند الكتابة. وقد نجح هذا المنفذ، ولكن نواة Accent الناتجة كانت ذات استخدام عملي محدود لأنها لم تكن تشغل برامج موجودة. وعلاوة على ذلك، كان نظام Accent مرتبطًا ارتباطًا وثيقًا بنظام PERQ كما كان نظام Aleph مرتبطًا بنظام Eclipse.

كان التغيير الرئيسي بين هذه النوى التجريبية وMach هو القرار بإنشاء نسخة من نواة 4.2BSD الحالية معاد تنفيذها على مفاهيم تمرير الرسائل Accent. ستكون هذه النواة متوافقة ثنائيًا مع برنامج BSD الحالي ، مما يجعل النظام متاحًا على الفور للاستخدام اليومي مع الاستمرار في كونه منصة تجريبية مفيدة. بالإضافة إلى ذلك، سيتم تصميم النواة الجديدة منذ البداية لدعم بنيات المعالج المتعددة، حتى السماح ببناء مجموعات غير متجانسة. من أجل تشغيل النظام بأسرع ما يمكن، سيتم تنفيذ النظام من خلال البدء بكود BSD الحالي، وإعادة تنفيذه تدريجيًا كبرامج تعتمد على الاتصالات بين العمليات (IPC-based). وبالتالي، سيبدأ Mach كنظام متجانس مشابه لأنظمة UNIX الحالية، ويتقدم نحو مفهوم النواة الصغيرة بمرور الوقت. ^[4]

بدأ Mach في الأساس كمحاولة لإنتاج Accent محددة بوضوح ومستندة إلى UNIX وقابلة للنقل بسهولة. وكانت النتيجة قائمة قصيرة من المفاهيم العامة: ^{[7] [8]}

• " المهمة " عبارة عن مجموعة من موارد النظام التي تنتج "خيوطًا" لتشغيلها
• " الخيط " هو وحدة تنفيذ واحدة موجودة في سياق مهمة وتشارك موارد المهمة
• " المنفذ " عبارة عن قائمة رسائل محمية للاتصال بين المهام؛ حيث تمتلك المهام حقوق الإرسال والاستقبال (الأذونات) لكل منفذ.
• " الرسائل " عبارة عن مجموعات من البيانات المكتوبة، ولا يمكن إرسالها إلا إلى المنافذ - وليس المهام أو الخيوط على وجه التحديد

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

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

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

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

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

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

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

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

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

أخيرًا، في ظل نظام Mach، تم تصميم كل هذه الميزات عمدًا لتكون محايدة للغاية فيما يتعلق بالمنصة. ولنقتبس نصًا واحدًا عن نظام Mach:

على عكس UNIX، الذي تم تطويره دون مراعاة تعدد المعالجات، يتضمن Mach دعمًا لتعدد المعالجات في جميع أنحاءه. كما أن دعمه لتعدد المعالجات مرن للغاية، ويتراوح من أنظمة الذاكرة المشتركة إلى الأنظمة التي لا تحتوي على ذاكرة مشتركة بين المعالجات. تم تصميم Mach للعمل على أنظمة كمبيوتر تتراوح من معالج واحد إلى آلاف المعالجات. بالإضافة إلى ذلك، يمكن نقل Mach بسهولة إلى العديد من بنيات الكمبيوتر المتنوعة. الهدف الرئيسي لـ Mach هو أن يكون نظامًا موزعًا قادرًا على العمل على أجهزة غير متجانسة. ^[9]

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

تم استضافة Mach في البداية ككود إضافي مكتوب مباشرة في نواة 4.2BSD الموجودة، مما يسمح للفريق بالعمل على النظام قبل وقت طويل من اكتماله. بدأ العمل بنظام Accent IPC/port الذي يعمل بالفعل، وانتقل إلى الأجزاء الرئيسية الأخرى من نظام التشغيل: المهام والخيوط والذاكرة الافتراضية. مع اكتمال الأجزاء، تمت إعادة كتابة أجزاء مختلفة من نظام BSD للاتصال بـ Mach، كما تم إجراء تغيير إلى 4.3BSD أثناء هذه العملية.

بحلول عام 1986، كان النظام مكتملًا إلى الحد الذي جعله قادرًا على العمل بمفرده على DEC VAX . وعلى الرغم من عدم تحقيق أي قيمة عملية، فقد تحقق هدف إنشاء نواة دقيقة. وسرعان ما تبع ذلك إصدارات على جهاز كمبيوتر IBM RT PC ومحطات العمل المستندة إلى Sun Microsystems 68030 ، مما أثبت قابلية نقل النظام. وبحلول عام 1987، تضمنت القائمة أجهزة Encore Multimax و Sequent Balance ، لاختبار قدرة Mach على العمل على أنظمة متعددة المعالجات. وتم إصدار الإصدار 1 العام في ذلك العام، وتبعه الإصدار 2 في العام التالي.

خلال هذه الفترة لم يتم الوفاء بالوعد بإنشاء نواة صغيرة "حقيقية". تضمنت إصدارات Mach المبكرة غالبية 4.3BSD في النواة، وهو نظام يُعرف باسم POE Server، مما أدى إلى نواة أكبر من UNIX التي كانت تستند إليها. ومع ذلك، كانت الفكرة هي نقل طبقة UNIX من النواة إلى مساحة المستخدم، حيث يمكن العمل عليها بسهولة أكبر وحتى استبدالها تمامًا. لسوء الحظ، ثبت أن الأداء يمثل مشكلة كبيرة، وتم إجراء عدد من التغييرات المعمارية من أجل حل هذه المشكلة. كما أزعجت مشكلات ترخيص UNIX الباحثين، لذلك استمر هذا الجهد المبكر لتوفير بيئة نظام غير مرخصة تشبه UNIX في العثور على استخدام، حتى وقت متأخر من تطوير Mach.

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

تلقى Mach دفعة كبيرة في الرؤية عندما أعلنت مؤسسة البرمجيات المفتوحة (OSF) أنها ستستضيف إصدارات مستقبلية من OSF/1 على Mach 2.5، وكانت تحقق في Mach 3 أيضًا. تم اختيار Mach 2.5 أيضًا لنظام NeXTSTEP وعدد من بائعي المعالجات المتعددة التجارية. أدى Mach 3 إلى عدد من الجهود لنقل أجزاء أنظمة التشغيل الأخرى إلى microkernel، بما في ذلك نظام التشغيل Workplace OS من IBM والعديد من الجهود التي بذلتها Apple لبناء إصدار متعدد الأنظمة الأساسية من نظام التشغيل Mac OS الكلاسيكي . ^[10] أظهر الباحثون دعم تشغيل تطبيقات DOS في بيئة Mach 3.0، في أعقاب العمل السابق في تشغيل نظام التشغيل Mac OS الكلاسيكي و MultiFinder تحت Mach 2.5. ^[11]

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

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

لسوء الحظ، تبين أن استخدام IPC لجميع المهام تقريبًا له تأثير خطير على الأداء. أظهرت الاختبارات المعيارية على أجهزة عام 1997 أن تنفيذات خادم UNIX الفردي المستندة إلى Mach 3.0 كانت أبطأ بنحو 50% من UNIX الأصلي. ^{[12] [13]}

أظهرت دراسة الطبيعة الدقيقة لمشاكل الأداء عددًا من الحقائق المثيرة للاهتمام. كان أحدها أن IPC لم يكن المشكلة: كان هناك بعض النفقات العامة المرتبطة بتعيين الذاكرة اللازمة لدعمه، لكن هذا أضاف فقط قدرًا صغيرًا من الوقت لإجراء مكالمة. أما الباقي، 80٪ من الوقت المستغرق، فكان بسبب المهام الإضافية التي كان النواة تقوم بتشغيلها على الرسائل. وكان من بين هذه المهام الأساسية التحقق من حقوق المنفذ وصلاحية الرسالة. في اختبارات المقاييس على 486 DX-50، استغرقت مكالمة نظام UNIX القياسية في المتوسط ​​21 ميكروثانية لإكمالها، بينما بلغ متوسط ​​العملية المكافئة مع Mach IPC 114 ميكروثانية. كان 18 ميكروثانية فقط من هذا الوقت متعلقًا بالأجهزة؛ أما الباقي فكان نواة Mach التي تقوم بتشغيل روتينات مختلفة على الرسالة. ^[14] نظرًا لأن مكالمة النظام لا تفعل شيئًا، فإن الرحلة ذهابًا وإيابًا كاملة تحت BSD تتطلب حوالي 40 ميكروثانية، بينما في نظام Mach في مساحة المستخدم، ستستغرق أقل من 500 ميكروثانية.

عندما تم استخدام Mach لأول مرة بجدية في إصدارات 2.x، كان الأداء أبطأ من أنظمة التشغيل التقليدية المتجانسة، ربما بنسبة 25%. ^[1] ومع ذلك، لم يتم اعتبار هذه التكلفة مثيرة للقلق بشكل خاص، لأن النظام كان يوفر أيضًا دعمًا متعدد المعالجات وسهولة النقل. شعر الكثيرون أن هذه تكلفة متوقعة ومقبولة. عندما حاول Mach 3 نقل معظم نظام التشغيل إلى مساحة المستخدم، أصبحت التكلفة أعلى: أظهرت المعايير بين Mach و Ultrix على MIPS R3000 انخفاضًا في الأداء يصل إلى 67% في بعض أحمال العمل. ^[15]

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

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

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

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

بدلاً من ذلك، التزم معظم المطورين بمفهوم POE الأصلي لخادم كبير واحد يوفر وظائف نظام التشغيل. ^[16] لتسهيل التطوير، سمحوا لخادم نظام التشغيل بالعمل إما في مساحة المستخدم أو مساحة النواة. سمح لهم هذا بالتطوير في مساحة المستخدم والحصول على جميع مزايا فكرة Mach الأصلية، ثم نقل الخادم الذي تم تصحيح أخطائه إلى مساحة النواة من أجل الحصول على أداء أفضل. تم إنشاء العديد من أنظمة التشغيل منذ ذلك الحين باستخدام هذه الطريقة، المعروفة باسم التواجد المشترك ، من بينها Lites و MkLinux و OSF/1 وNeXTSTEP/OPENSTEP/macOS. جعلت نواة Chorus الصغيرة هذه ميزة للنظام الأساسي، مما يسمح برفع الخوادم إلى مساحة النواة باستخدام آليات مدمجة.

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

بحلول منتصف تسعينيات القرن العشرين، كان العمل على أنظمة النواة الدقيقة راكدًا إلى حد كبير، على الرغم من اعتقاد السوق عمومًا أن جميع أنظمة التشغيل الحديثة ستكون مبنية على النواة الدقيقة بحلول تسعينيات القرن العشرين. الاستخدامات الأساسية المتبقية على نطاق واسع لنواة Mach هي نظام التشغيل macOS من Apple ونظام التشغيل iOS الشقيق له، والذي يعمل على نواة Mach الهجينة المعدلة بشدة من Open Software Foundation (OSFMK 7.3) والتي تسمى " XNU " ^[17] والتي تُستخدم أيضًا في OSF/1. ^[10] في XNU، يتم تنفيذ أنظمة الملفات ومجموعات الشبكات ووظائف إدارة العمليات والذاكرة في النواة؛ ويتم استدعاء نظام الملفات والشبكات وبعض وظائف إدارة العمليات والذاكرة من وضع المستخدم عبر مكالمات النظام العادية بدلاً من تمرير الرسائل؛ ^{[18] [19]} تُستخدم رسائل Mach الخاصة بـ XNU للاتصال بين عمليات وضع المستخدم، ولبعض الطلبات من كود وضع المستخدم إلى النواة ومن النواة إلى خوادم وضع المستخدم.

أظهر التحليل الإضافي أن مشكلة أداء IPC لم تكن واضحة كما بدت. تذكر أن جانبًا واحدًا من نداء النظام استغرق 20 ميكروثانية تحت BSD ^[3] و114 ميكروثانية على Mach يعمل على نفس النظام. ^[2] من أصل 114، كان 11 بسبب تبديل السياق، مطابقًا لـ BSD. ^[13] تم استخدام 18 إضافيًا بواسطة MMU لرسم خريطة الرسالة بين مساحة المستخدم ومساحة النواة. ^[3] يصل هذا إلى 29 ميكروثانية فقط، أطول من نداء النظام التقليدي، ولكن ليس كثيرًا.

أما الباقي، وهو الجزء الأكبر من المشكلة الفعلية، فكان بسبب قيام النواة بأداء مهام مثل التحقق من الرسالة بحثًا عن حقوق الوصول إلى المنفذ. ^[6] وفي حين قد يبدو هذا مصدر قلق أمني مهم، إلا أنه في الواقع لا يكون منطقيًا إلا في نظام يشبه يونكس. على سبيل المثال، قد لا يحتاج نظام تشغيل مستخدم واحد يشغل هاتفًا محمولًا أو روبوتًا إلى أي من هذه الميزات، وهذا هو بالضبط نوع النظام الذي سيكون فيه نظام التشغيل الاختياري الخاص بـ Mach هو الأكثر قيمة. وبالمثل، تسبب Mach في حدوث مشكلات عندما تم نقل الذاكرة بواسطة نظام التشغيل، وهي مهمة أخرى لا تكون منطقية حقًا إلا إذا كان النظام يحتوي على أكثر من مساحة عنوان واحدة. يحتوي نظام التشغيل DOS ونظام التشغيل Mac OS المبكر على مساحة عنوان كبيرة واحدة مشتركة بين جميع البرامج، لذلك في ظل هذه الأنظمة لم توفر التعيين أي فوائد.

أدت هذه الإنجازات إلى سلسلة من نوى الجيل الثاني، والتي قللت بشكل أكبر من تعقيد النظام ووضعت جميع الوظائف تقريبًا في مساحة المستخدم. على سبيل المثال، تتضمن نواة L4 (الإصدار 2) سبع مكالمات نظام فقط وتستخدم 12 كيلو بايت من الذاكرة، ^[3] بينما تتضمن Mach 3 حوالي 140 وظيفة وتستخدم حوالي 330 كيلو بايت من الذاكرة. ^[3] تستغرق مكالمات IPC تحت L4 على 486DX-50 5 ميكروثانية فقط، ^[19] أسرع من مكالمة نظام UNIX على نفس النظام، وأكثر من 20 مرة أسرع من Mach. بالطبع هذا يتجاهل حقيقة أن L4 لا يتعامل مع الأذونات أو الأمان؛ ولكن من خلال ترك هذا لبرامج مساحة المستخدم، يمكنهم تحديد قدر كبير أو قليل من النفقات العامة حسب متطلباتهم.

إن المكاسب المحتملة في الأداء التي يحققها L4 تتضاءل بسبب حقيقة مفادها أن تطبيقات مساحة المستخدم غالبًا ما يتعين عليها توفير العديد من الوظائف التي كانت تدعمها نواة النظام سابقًا. ومن أجل اختبار الأداء الشامل، تمت مقارنة MkLinux في وضع التواجد المشترك بمنفذ L4 يعمل في مساحة المستخدم. أضاف L4 حوالي 5% إلى 10% من النفقات العامة، ^[13] مقارنة بـ 29% التي يضيفها Mach. ^[13]

فيما يلي قائمة بأنوية أنظمة التشغيل المشتقة من Mach وأنظمة التشغيل ذات الأنوية المشتقة من Mach:

• النواة الدقيقة
• عائلة L4 من النواة الصغيرة
• عائلة نواة EROS
• ميرت

• الموقع الرسمي ، الصفحة الرئيسية لمشروع Mach لعلوم الكمبيوتر بجامعة كارنيجي ميلون
• نظام ماخ – ملحق لمفاهيم نظام التشغيل (الطبعة الثامنة) بقلم آفي سيلبيرشاتز، وبيتر بير جالفين، وجريج جاجن
• مقارنة بين Mach وAmoeba وChorus
• نحو نوى دقيقة حقيقية – يحتوي على العديد من قياسات الأداء، بما في ذلك تلك المذكورة في المقالة
• أداء الأنظمة القائمة على µ-Kernel – يحتوي على مقارنة أداء ممتازة لنظام Linux الذي يعمل كنواة أحادية، على Mach 3 وعلى L4
• كود مصدر نواة Mach - إصدار قابل للتصفح من كود مصدر نواة Mach على موقع مرجعي متقاطع لنواة FreeBSD/Linux
• كشف أسطورة Mac OS X Microkernel
• Loepere, Keith. "MK++: A High Performance, High Assurance Microkernel". مؤرشف من الأصل في 22 أغسطس 2017. تم الاسترجاع في 22 أغسطس 2017 .