بنية ara::core::PoolOptions

يُستخدم الهيكل ara::core::PoolOptions لتكوين موارد الذاكرة القائمة على تجمعات الذاكرة وفقًا لـ std::pmr::pool_options. وهو يتيح تقييد الحد الأقصى لعدد الكتل لكل جزء (Chunk) عبر max_blocks_per_chunk [SWS_CORE_00027] وتحديد الحد الأقصى لحجم كتلة تجمع الذاكرة عبر largest_required_pool_block [SWS_CORE_00028]. وباعتباره مجمّع بيانات بسيطًا، يتم ملء الهيكل قبل تهيئة مورد الذاكرة وتمريره إلى دالة البناء الخاصة به. تفسير: نظرًا لعدم وجود تحقق داخلي، يجب على المطورين التأكد من أن قيم العتبة المكونة لا تتجاوز سعة الذاكرة الرئيسية الفعلية. سؤال (مفتوح)

المزيد ›

السياق

يوفر هيكل البيانات ara::core::PoolOptions معلمات تكوين للموارد القائمة على تجمعات الذاكرة في الوحدة core لـ AUTOSAR Adaptive Platform. وهو يخدم التحكم المستهدف في سلوك التخصيص ويسترشد بوظائف C++ القياسية لـ std::pmr::pool_options. يتم تضمين الهيكل عبر الترويسة <ara/core/memory_resource.h> ويتفاعل بشكل وثيق مع موارد ذاكرة التجمع، التي تحتفظ بأجزاء (Chunks) وكتل متصلة لطلبات الذاكرة المتكررة.

في الأنظمة الحرجة للسلامة والقريبة من الوقت الحقيقي، يعد تحديد العمليات الديناميكية للذاكرة وإمكانية التنبؤ بها أمرًا جوهريًا. ويتولى ara::core::PoolOptions في هذا السياق دور أداة الفصل بين متطلبات السعة الخاصة بالتطبيق والإدارة الداخلية لتجمعات الذاكرة. ومن خلال الهيكل، يمكن للمطورين تحديد الحد الأقصى لعدد الكتل المسموح بدمجها داخل جزء واحد [SWS_CORE_00027] والحد الأقصى لحجم الكتلة الذي لا يزال يتعين خدمته عبر التجمعات المتخصصة [SWS_CORE_00028]. وتستخدم برمجيات التطبيق، التي تنشئ نسخًا من موارد الذاكرة، هذه الخيارات لتجنب التجزئة المفرطة والتحكم في حدود التخصيص بشكل حتمي.

دورة الحياة

كنوع تكوين بسيط (struct)، يمتلك ara::core::PoolOptions دورة حياة خفيفة الوزن دون انتقالات حالة داخلية معقدة. وعادةً ما يتم الإنشاء ككائن مكدس محلي أو كثابت تكوين ساكن قبل إنشاء مورد الذاكرة المرتبط به. وعند إنشاء النسخة، تتم تهيئة الخاصيتين max_blocks_per_chunk [SWS_CORE_00027] وlargest_required_pool_block [SWS_CORE_00028] افتراضيًا بالقيمة 0.

تفسير: من المحتمل أن تشير القيمة 0 لمورد الذاكرة المستقبِل إلى وجوب تطبيق الحدود القياسية الخاصة بالمنصة. سؤال (مفتوح) وبما أنه كائن قيمة صرف، فإن ara::core::PoolOptions لا يمتلك موارد بالمعنى المقصود في RAII ولا ينفذ أي إجراءات تنظيف عند التدمير. وتكون دورة حياة الهيكل عادةً مرتبطة بمرحلة إنشاء مورد الذاكرة: بمجرد تمرير الخيارات إلى مورد التجمع، يحتفظ المورد بالمعلمات داخليًا، بحيث يمكن تدمير كائن PoolOptions نفسه أو إعادة استخدامه دون مخاطر.

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

مسار الاستخدام

تتضمن حالة الاستخدام الأساسية تحديد حدود التخصيص وتمريرها إلى مكون يدير الذاكرة. في البداية، ينشئ المتصل نسخة من ara::core::PoolOptions ويملأ المعلمات المطلوبة. ويتم عبر max_blocks_per_chunk تحديد الحد الأعلى للكتل لكل جزء [SWS_CORE_00027]، بينما يحدد largest_required_pool_block الحد الأعلى لعمليات التخصيص التي لا يزال يتعين تغطيتها بواسطة تجمع الذاكرة [SWS_CORE_00028].

بعد ذلك، يتم تمرير الهيكل الذي تم ملؤه إلى دالة البناء لمورد ذاكرة التجمع المعني. يقرأ مورد الذاكرة القيم المكونة ويُعدّ تجمعاته الداخلية وفقًا لذلك. وإذا وردت طلبات ذاكرة أثناء التشغيل، يقرر المورد بناءً على قيم العتبة المكونة مسبقًا ما إذا كان يمكن تلبية الطلب من تجمع الذاكرة أو ما إذا كان يجب إعادة توجيهه إلى مورد ذي مستوى أعلى في المنبع (Upstream). تفسير: يُفترض أن الطلبات التي تتجاوز largest_required_pool_block يتم عادةً تفويضها مباشرةً إلى مدير الذاكرة ذي المستوى الأعلى. سؤال (مفتوح)

مخطط تسلسلي: المسار النموذجي لتكوين مورد ذاكرة تجمع عبر PoolOptions. المصادر: [SWS_CORE_00027]، [SWS_CORE_00028].

سيناريوهات الأخطاء

نظرًا لأن ara::core::PoolOptions معرّف كمجمّع بيانات بسيط (struct)، فإن إنشاء الحقول أو ملأها لا يطلق أي استثناءات C++ ولا يُرجع أي رموز أخطاء. وتنشأ ظروف الأخطاء المحتملة فقط عند تفسير القيم بواسطة مورد الذاكرة المستقبِل.

تفسير: إذا تم تكوين قيم غير واقعية — على سبيل المثال قيمة كبيرة للغاية لـ max_blocks_per_chunk [SWS_CORE_00027] أو لـ largest_required_pool_block [SWS_CORE_00028] — فقد يؤدي ذلك إلى اصطدام مورد الذاكرة اللاحق بحدود النظام عند تخصيص الأجزاء وإطلاق حالات نفاد الذاكرة (Out-of-Memory). سؤال (مفتوح) ولذلك، فإن الشرط المسبق للتشغيل المستقر هو المواءمة الدقيقة لكلا المعلمتين مع الذاكرة الرئيسية المتاحة فعليًا وملف تعريف الحمل المتوقع للتطبيق. وإذا بقيت القيم عند 0، فإنه يقع على عاتق المورد المستهدف تطبيق أحجام افتراضية متينة.