مصدر النقل المثبت: هل يجوز تغييره قبل اكتمال النسخ؟

الخلاصة السريعة

لا تعتمد على عودة الاستدعاء لإباحة تعديل المصدر المثبت؛ احتفظ بالبيانات المطلوبة ثابتة إلى أن تعرف اكتمال النقل المعني.

• يحذر الدليل من تعديل مصدر في ذاكرة مثبتة أثناء نقل غير حاجب من المضيف إلى CUDA؛ الحكم هنا مقيد بهذا السيناريو. ^[1]
• في عقدنا المكتوب يقرأ الناسخ العنصر الأول 8، ثم نبدل المصدر إلى 40 و 41، ثم يقرأ الثاني 41؛ النتيجة المفترضة 8 و 41 ليست أيا من النسختين الكاملة.
• إذا ثبتنا المصدر 8 و 9 حتى انتهاء القراءتين، يجمع العقد 8 و 9؛ بديل النسخة المستقلة يحتاج إلى تحقق الاستقلال، لا اسم جديد للمصدر نفسه.
• راجع ثبات المصدر ودليل انتهاء استعماله قبل إعادة الكتابة؛ لا نعمم منع التعديل على كل اتجاه وذاكرة، ولم ننقل بيانات أو نثبت أن الخلط يحدث دائما.

ما المصدر الذي يحتاج إلى الثبات؟

يبين دليل PyTorch أن تعديل مصدر مثبت بعد نقل غير حاجب من المضيف إلى CUDA قد يفسد البيانات المستلمة. ^[1]

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

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

كيف يصنع ترتيب القراءات نسخة مختلطة؟

نؤلف ناسخا تعليميا يقرأ عنصرين في خطوتين منفصلتين. يبدأ المصدر بالقيمتين 8 و 9. نعلن أن أول قراءة تأخذ العنصر الأول فتسجل 8، ثم يعود التحكم في سيناريو ورقي يسمح بتعديل المصدر.

قبل القراءة الثانية نبدل القيمتين إلى 40 و 41. يقرأ الناسخ العنصر الثاني من المصدر الحالي فيأخذ 41. بحسب ترتيبنا المعلن، الجواب المجمع هو 8 و 41، وليس 8 و 9 ولا 40 و 41.

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

ما الفرق بين ثبات المصدر واسم جديد؟

نؤلف فرعا يحفظ المصدر 8 و 9 حتى انتهاء القراءتين. تحت الناسخ نفسه يحصل الجواب على 8 و 9. وبعد انتهاء استعمال المصدر في هذا العقد يمكن كتابة 40 و 41 دون تغيير ما اكتمل نسخه.

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

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

ما الدليل الذي يسمح بإعادة استعمال المصدر؟

نقترح بطاقة تنقل هوية المصدر والوجهة ونوع الذاكرة وحدود استعمال المصدر ودليل انتهاء العمل المعني. كلمة «عاد» دون بيان الحدث لا تثبت أن الناسخ أنهى قراءته.

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

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