النظام والحاجز: ما هي التعليمات المكافئة على x86 لـ "LWSYNC" على PowerPC؟

Question

الكود الخاص بي بسيط على النحو التالي. وجدت RMB و WMB للقراءة والكتابة ، ولكن لم يجد واحدة عامة.lwsync متوفر على PowerPC ، ولكن ما هو بديل X86؟ شكرًا مقدمًا.

#define barrier() __asm__ volatile ("lwsync")
...
    lock()
    if(!pInst);
    {
        T* temp=new T;
        barrier();
        pInst=temp;
    }
    unlock();

Answer 1

rmb() و WMB () هي وظائف Kernel Linux. يوجد ايضا mb().

تعليمات x86 lfence, sfence, ، و mfence, ، iirc.

Answer 2

يوجد ملف معين في وقت تشغيل Cilk قد تجد IE Cilk-sysdep.h حيث يحتوي على حواجز ذاكرة محددة للنظام. أنا استخراج قسم صغير wrt urs or on x86 أي i386

    file:-- cilk-sysdep.h (the numbers on the LHS are actually line numbers)

    252      * We use an xchg instruction to serialize memory accesses, as can
    253      * be done according to the Intel Architecture Software Developer's
    254      * Manual, Volume 3: System Programming Guide
    255      * (http://www.intel.com/design/pro/manuals/243192.htm), page 7-6,
    256      * "For the P6 family processors, locked operations serialize all
    257      * outstanding load and store operations (that is, wait for them to
    258      * complete)."  The xchg instruction is a locked operation by
    259      * default.  Note that the recommended memory barrier is the cpuid
    260      * instruction, which is really slow (~70 cycles).  In contrast,
    261      * xchg is only about 23 cycles (plus a few per write buffer
    262      * entry?).  Still slow, but the best I can find.  -KHR 
    263      *
    264      * Bradley also timed "mfence", and on a Pentium IV xchgl is still quite a bit faster
    265      *   mfence appears to take about 125 ns on a 2.5GHZ P4
    266      *   xchgl  apears  to take about  90 ns on a 2.5GHZ P4
    267      * However on an opteron, the performance of mfence and xchgl are both *MUCH MUCH   BETTER*.
    268      *   mfence takes 8ns on a 1.5GHZ AMD64 (maybe this is an 801)
    269      *   sfence takes 5ns
    270      *   lfence takes 3ns
    271      *   xchgl  takes 14ns
    272      * see mfence-benchmark.c
    273      */
    274     int x=0, y;
    275     __asm__ volatile ("xchgl %0,%1" :"=r" (x) :"m" (y), "0" (x) :"memory");
    276    }

ما أعجبني في هذا الأمر هو حقيقة أن Xchgl يبدو أسرع :) على الرغم من أنه يجب عليك تنفيذها حقًا والتحقق من ذلك.

Answer 3

لا تقل بالضبط ما هو القفل وفتح في هذا الرمز. أفترض أنها عمليات mutex. على powerpc ، ستستخدم وظيفة الحصول على mutex isync (يمكن بدونها تقييم الجهاز الخاص بك if (! pinst) قبل القفل ()) ، وسيكون لديه lwsync (أو المزامنة إذا كان تطبيق mutex قديمًا) في فتح () .

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

في X86 و X64 ، سيستخدم Lock () شكلاً من أشكال التعليمات المسبقة ، والتي لديها تلقائيًا سلوك المبارزة ثنائية الاتجاه.

يجب أن يكون إلغاء تأمينك على X86 و X64 مجرد تعليمات للمخزن (إلا إذا كنت تستخدم بعض تعليمات السلسلة الخاصة داخل CS ، وفي هذه الحالة ستحتاج إلى sfence).

الدليل:

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-anchitectures-software-developer-manual-325462.pdf

لديه معلومات جيدة عن جميع الأسوار وكذلك تأثيرات بادئة القفل (وعندما يكون ذلك ضمنيًا).

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