المعطيات¶

تُشير المعطاة uaddr إلى كلمة الفوتكس. في جميع المنصات، الفوتكسات هي أعداد صحيحة من أربعة بايتات يجب محاذاتها على حد أربعة بايتات. تُحدد العملية المطلوب تنفيذها على الفوتكس في المعطاة futex_op؛ و val هي قيمة يعتمد معناها والغرض منها على futex_op.

المعطيات المتبقية (timeout، و uaddr2، و val3) مطلوبة فقط لعمليات فوتكس معينة موصوفة أدناه. وعندما لا تكون إحدى هذه المعطيات مطلوبة، تُتجاهل.

بالنسبة لعدة عمليات حاصرة، تكون المعطاة timeout مؤشراً إلى هيكل timespec يحدد مهلة للعملية. ومع ذلك، وبالرغم من النموذج الموضح أعلاه، ففي بعض العمليات، تُستخدم البايتات الأربعة الأقل أهمية من هذه المعطاة بدلاً من ذلك كعدد صحيح يحدد معناه بواسطة العملية. لهذه العمليات، تحول النواة قيمة timeout أولاً إلى unsigned long، ثم إلى uint32_t، وفي بقية هذه الصفحة، يشار إلى هذه المعطاة باسم val2 عند تفسيرها بهذا الأسلوب.

عندما تكون مطلوبة، تكون المعطاة uaddr2 مؤشراً إلى كلمة فوتكس ثانية تستخدمها العملية.

تعتمد ترجمة المعطاة الصحيحة النهائية، val3، على العملية.

عمليات Futex¶

تتكون المعطاة futex_op من جزأين: أمر يحدد العملية المراد تنفيذها، معمول له OR بتياً مع خيار واحد أو أكثر من الخيارات التي تعدل سلوك العملية. الخيارات التي قد تُضمّن في futex_op هي كما يلي:

FUTEX_PRIVATE_FLAG (منذ لينكس 2.6.22)

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

من باب التسهيل، يعرّف <linux/futex.h> مجموعة من الثوابت باللاحقة _PRIVATE التي تكافئ جميع العمليات المدرجة أدناه، ولكن مع دمج FUTEX_PRIVATE_FLAG في قيمة الثابت عبر عملية OR. وبذلك، توجد FUTEX_WAIT_PRIVATE وFUTEX_WAKE_PRIVATE، وهكذا.

FUTEX_CLOCK_REALTIME (منذ لينكس 2.6.28)

لا يمكن استخدام بت الخيار هذا إلا مع عمليات FUTEX_WAIT_BITSET، و FUTEX_WAIT_REQUEUE_PI، و (منذ لينكس 4.5) FUTEX_WAIT، و (منذ لينكس 5.14) FUTEX_LOCK_PI2.

إذا ضُبط هذا الخيار، تقيس النواة مهلة الانتظار timeout مقابل ساعة الوقت الحقيقي CLOCK_REALTIME.

إذا لم يُضبط هذا الخيار، تقيس النواة مهلة الانتظار timeout مقابل ساعة الوقت الرتيب CLOCK_MONOTONIC.

العملية المحددة في futex_op هي واحدة مما يلي:

FUTEX_WAIT (منذ لينكس 2.6.0)

تختبر هذه العملية ما إذا كانت القيمة في كلمة الفوتكس التي يشير إليها العنوان uaddr لا تزال تحتوي على القيمة المتوقعة val، وإذا كان الأمر كذلك، فإنها تنام في انتظار عملية FUTEX_WAKE على كلمة الفوتكس. تحميل قيمة كلمة الفوتكس هو وصول ذري للذاكرة (أي باستخدام تعليمات الآلة الذرية للبنية المعنية). يُنفذ هذا التحميل، والمقارنة مع القيمة المتوقعة، وبدء النوم بشكل ذري وبترتيب كلي بالنسبة لعمليات فوتكس الأخرى على نفس كلمة الفوتكس. إذا بدأ الخيط في النوم، فيُعتبر منتظراً على كلمة الفوتكس هذه. إذا لم تتطابق قيمة الفوتكس مع val، فستفشل المكالمة فوراً مع الخطأ EAGAIN.

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

إذا كانت timeout ليست NULL، فإن الهيكل الذي تشير إليه يحدد مهلة للانتظار. (سيتم تقريب هذه الفترة إلى دقة ساعة النظام، ومن المضمون عدم انتهاء صلاحيتها مبكراً.) تُقاس المهلة مبدئياً وفقاً لساعة CLOCK_MONOTONIC، ولكن منذ لينكس 4.5، يمكن اختيار ساعة CLOCK_REALTIME بتحديد FUTEX_CLOCK_REALTIME في futex_op. إذا كانت timeout هي NULL، فستُحصر المكالمة إلى أجل غير مسمى.

ملاحظة: بالنسبة لـ FUTEX_WAIT، تُفسر timeout كقيمة نسبية. وهذا يختلف عن عمليات فوتكس الأخرى، حيث تُفسر timeout كقيمة مطلقة. للحصول على ما يعادل FUTEX_WAIT بمهلة مطلقة، استخدم FUTEX_WAIT_BITSET مع تحديد val3 كـ FUTEX_BITSET_MATCH_ANY.

تُتجاهل المعطيات uaddr2 و val3.

FUTEX_WAKE (منذ لينكس 2.6.0)

توقظ هذه العملية على الأكثر val من المنتظرين الذين ينتظرون (على سبيل المثال، داخل FUTEX_WAIT) على كلمة الفوتكس في العنوان uaddr. الأكثر شيوعاً هو تحديد val كـ 1 (إيقاظ منتظر واحد) أو INT_MAX (إيقاظ جميع المنتظرين). لا يُقدم أي ضمان بشأن المنتظرين الذين سيتم إيقاظهم (على سبيل المثال، لا يضمن إيقاظ منتظر ذي أولوية جدولة أعلى قبل منتظر ذي أولوية أقل).

تُتجاهل المعطيات timeout، و uaddr2، و val3.

FUTEX_FD (من لينكس 2.6.0 حتى لينكس 2.6.25 بما في ذلك)

تنشئ هذه العملية واصف ملف مرتبطاً بالفوتكس عند uaddr. يجب على المستدعِي إغلاق واصف الملف المعاد بعد الاستخدام. عندما تقوم عملية أو خيط آخر بتنفيذ FUTEX_WAKE على كلمة الفوتكس، يشير واصف الملف إلى أنه قابل للقراءة باستخدام select(2)، و poll(2)، و epoll(7)

يمكن استخدام واصف الملف للحصول على إشعارات غير متزامنة: إذا كانت val غير صفرية، فعندما تقوم عملية أو خيط آخر بتنفيذ FUTEX_WAKE، سيتلقى المستدعِي رقم الإشارة الذي تم تمريره في val.

تُتجاهل المعطيات timeout، و uaddr2، و val3.

نظراً لأنه كان ينطوي بطبيعته على تنافس، فقد حُذف FUTEX_FD من لينكس 2.6.26 فصاعداً.

FUTEX_REQUEUE (منذ لينكس 2.6.0)

تؤدي هذه العملية نفس المهمة التي تؤديها FUTEX_CMP_REQUEUE (انظر أدناه)، باستثناء أنه لا يتم إجراء أي فحص باستخدام القيمة في val3. (تُتجاهل المعطاة val3.)

FUTEX_CMP_REQUEUE (منذ لينكس 2.6.7)

تتحقق هذه العملية أولاً مما إذا كان الموقع uaddr لا يزال يحتوي على القيمة val3. إذا لم يكن الأمر كذلك، تفشل العملية مع الخطأ EAGAIN. وإلا، فإن العملية توقظ حداً أقصى قدره val من المنتظرين الذين ينتظرون على الفوتكس عند uaddr. إذا كان هناك أكثر من val من المنتظرين، فسيتم حذف المنتظرين المتبقين من صف انتظار فوتكس المصدر عند uaddr وإضافتهم إلى صف انتظار فوتكس الهدف عند uaddr2. تحدد المعطاة val2 حداً أقصى لعدد المنتظرين الذين سيتم نقلهم إلى صف فوتكس آخر عند uaddr2.

التحميل من uaddr هو وصول ذري للذاكرة (أي باستخدام تعليمات الآلة الذرية للبنية المعنية). يُنفذ هذا التحميل، والمقارنة مع val3، وإعادة وضع أي منتظرين في صف آخر بشكل ذري وبترتيب كلي بالنسبة للعمليات الأخرى على نفس كلمة الفوتكس.

القيم النموذجية لتحديد val هي 0 أو 1. (تحديد INT_MAX غير مفيد، لأنه سيجعل عملية FUTEX_CMP_REQUEUE مكافئة لـ FUTEX_WAKE.) قيمة الحد المحددة عبر val2 هي عادةً إما 1 أو INT_MAX. (تحديد المعطاة كـ 0 غير مفيد، لأنه سيجعل عملية FUTEX_CMP_REQUEUE مكافئة لـ FUTEX_WAIT.)

أُضيفت عملية FUTEX_CMP_REQUEUE كبديل لعملية FUTEX_REQUEUE السابقة. والفرق هو أن التحقق من القيمة عند uaddr يمكن استخدامه لضمان حدوث إعادة الصف فقط في ظل ظروف معينة، مما يسمح بتجنب حالات التسابق في حالات استخدام معينة.

يمكن استخدام كل من FUTEX_REQUEUE و FUTEX_CMP_REQUEUE لتجنب تنبيهات "القطيع الهائج" التي قد تحدث عند استخدام FUTEX_WAKE في الحالات التي يحتاج فيها جميع المنتظرين الذين تم إيقاظهم إلى حيازة فوتكس آخر. تأمل السيناريو التالي، حيث تنتظر خيوط منتظرين متعددة على B، وهو صف انتظار نُفذ باستخدام فوتكس:

lock(A)
while (!check_value(V)) {


    unlock(A);


    block_on(B);


    lock(A);
};
unlock(A);
    

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

FUTEX_WAKE_OP (منذ لينكس 2.6.14)

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

عملية FUTEX_WAKE_OP تعادل تنفيذ الكود التالي بشكل ذري وبترتيب كلي فيما يتعلق بعمليات فوتكس الأخرى على أي من كلمتي فوتكس المقدمتين:

uint32_t oldval = *(uint32_t *) uaddr2;
*(uint32_t *) uaddr2 = oldval op oparg;
futex(uaddr, FUTEX_WAKE, val, 0, 0, 0);
if (oldval cmp cmparg)


    futex(uaddr2, FUTEX_WAKE, val2, 0, 0, 0);
    

بعبارة أخرى، يقوم FUTEX_WAKE_OP بما يلي:

تُرمز العملية والمقارنة المراد تنفيذهما في بتات المعطاة val3. بالرسم، التشفير هو:

+---+---+-----------+-----------+
|op |cmp|   oparg   |  cmparg   |
+---+---+-----------+-----------+


  4   4       12          12    <== عدد البتات
    

معبراً عنه بالكود، التشفير هو:

#define FUTEX_OP(op, oparg, cmp, cmparg) \


                (((op & 0xf) << 28) | \


                ((cmp & 0xf) << 24) | \


                ((oparg & 0xfff) << 12) | \


                (cmparg & 0xfff))
    

فيما سبق، op و cmp كل منهما كود من الأكواد المدرجة أدناه. المكونان oparg و cmparg هما قيم عددية حرفية، إلا كما هو موضح أدناه.

يحتوي المكون op على إحدى القيم التالية:

FUTEX_OP_SET        0  /* uaddr2 = oparg; */
FUTEX_OP_ADD        1  /* uaddr2 += oparg; */
FUTEX_OP_OR         2  /* uaddr2 |= oparg; */
FUTEX_OP_ANDN       3  /* uaddr2 &= ~oparg; */
FUTEX_OP_XOR        4  /* uaddr2 ^= oparg; */
    

بالإضافة إلى ذلك، فإن إجراء OR بتياً للقيمة التالية في op يؤدي إلى استخدام (1 << oparg) كـ معامل:

FUTEX_OP_ARG_SHIFT  8  /* استخدم (1 << oparg) كمعامل */
    

حقل cmp هو واحد مما يلي:

FUTEX_OP_CMP_EQ     0  /* إذا كان (oldval == cmparg) استيقظ */
FUTEX_OP_CMP_NE     1  /* إذا كان (oldval != cmparg) استيقظ */
FUTEX_OP_CMP_LT     2  /* إذا كان (oldval < cmparg) استيقظ */
FUTEX_OP_CMP_LE     3  /* إذا كان (oldval <= cmparg) استيقظ */
FUTEX_OP_CMP_GT     4  /* إذا كان (oldval > cmparg) استيقظ */
FUTEX_OP_CMP_GE     5  /* إذا كان (oldval >= cmparg) استيقظ */
    

قيمة الإرجاع لـ FUTEX_WAKE_OP هي مجموع عدد المنتظرين الذين استيقظوا على فوتكس uaddr بالإضافة إلى عدد المنتظرين الذين استيقظوا على فوتكس uaddr2.

FUTEX_WAIT_BITSET (منذ لينكس 2.6.25)

تشبه هذه العملية FUTEX_WAIT باستثناء أن val3 يُستخدم لتوفير قناع بتات 32 بت لـ النواة. يُخزن قناع البتات هذا، والذي يجب ضبط بت واحد على الأقل فيه، في الحالة الداخلية لـ النواة للمنتظر. انظر وصف FUTEX_WAKE_BITSET لمزيد من التفاصيل.

إذا كانت timeout ليست NULL، فإن الهيكل الذي تشير إليه يحدد مهلة مطلقة لعملية الانتظار. إذا كانت timeout هي NULL، يمكن حصر العملية إلى أجل غير مسمى.

تُتجاهل المعطاة uaddr2.

FUTEX_WAKE_BITSET (منذ لينكس 2.6.25)

هذه العملية هي نفسها FUTEX_WAKE باستثناء أن المعطاة val3 تُستخدم لتوفير قناع بتات 32 بت لـ النواة. يُستخدم قناع البتات هذا، والذي يجب ضبط بت واحد على الأقل فيه، لتحديد المنتظرين الذين يجب إيقاظهم. يتم التحديد بواسطة AND بتياً لقناع بتات "التنبيه" (أي القيمة في val3) وقناع البتات المخزن في الحالة الداخلية لـ النواة للمنتظر (قناع بتات "الانتظار" الذي يتم ضبطه باستخدام FUTEX_WAIT_BITSET). يتم إيقاظ جميع المنتظرين الذين تكون نتيجة AND لهم غير صفرية؛ ويُترك المنتظرون المتبقون نائمين.

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

يمكن استخدام الثابت FUTEX_BITSET_MATCH_ANY، الذي يتوافق مع ضبط جميع البتات الـ 32 في قناع البتات، كـ معطاة val3 لـ FUTEX_WAIT_BITSET و FUTEX_WAKE_BITSET. وبخلاف الاختلافات في معالجة المعطاة timeout، فإن عملية FUTEX_WAIT تعادل FUTEX_WAIT_BITSET مع تحديد val3 كـ FUTEX_BITSET_MATCH_ANY؛ أي السماح بالتنبيه من قبل أي منبه. عملية FUTEX_WAKE تعادل FUTEX_WAKE_BITSET مع تحديد val3 كـ FUTEX_BITSET_MATCH_ANY؛ أي إيقاظ أي منتظر (أو منتظرين).

تُتجاهل المعطيات uaddr2 و timeout.

Futexes توريث الأولويات¶

يدعم لينكس futexes توريث الأولويات (PI) للتعامل مع مشكلات انعكاس الأولويات التي قد تواجه أقفال futex العادية. انعكاس الأولويات هو المشكلة التي تحدث عندما تُحبس مهمة عالية الأولوية بانتظار الاستحواذ على قفل تملكه مهمة منخفضة الأولوية، بينما تقوم مهام ذات أولوية متوسطة باستمرار بإزاحة المهمة منخفضة الأولوية من المعالج. ونتيجة لذلك، لا تحرز المهمة منخفضة الأولوية أي تقدم نحو تحرير القفل، وتظل المهمة عالية الأولوية محبوسة.

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

من منظور مساحة المستخدم، ما يجعل الـ futex مدركًا لتوريث الأولويات (PI-aware) هو اتفاق سياسة (موصوف أدناه) بين مساحة المستخدم والنواة حول قيمة كلمة futex، مقترنًا باستخدام عمليات PI-futex الموضحة أدناه. (على عكس عمليات futex الأخرى الموضحة أعلاه، صُممت عمليات PI-futex لتنفيذ آليات اتصال بين العمليات (IPC) محددة للغاية).

تختلف عمليات PI-futex الموضحة أدناه عن عمليات futex الأخرى في أنها تفرض سياسة على استخدام قيمة كلمة futex:

•

إذا لم يُستحوذ على القفل، يجب أن تكون قيمة كلمة futex هي 0.

•

إذا استُحوذ على القفل، يجب أن تكون قيمة كلمة futex هي معرف الخيط (TID؛ انظر gettid(2)) للخيط المالك.

•

إذا كان القفل مملوكًا وهناك خيوط تتنازع عليه، يجب ضبط بت FUTEX_WAITERS في قيمة كلمة futex؛ بعبارة أخرى، هذه القيمة هي:

FUTEX_WAITERS | TID
    

(لاحظ أنه من غير الصالح أن تكون كلمة PI futex بلا مالك مع ضبط FUTEX_WAITERS).

مع تطبيق هذه السياسة، يمكن لتطبيق مساحة المستخدم الاستحواذ على قفل غير مستحوذ عليه أو تحرير قفل باستخدام تعليمات ذرية تُنفذ في وضع المستخدم (على سبيل المثال، عملية مقارنة وتبديل مثل cmpxchg في معمارية x86). يتكون الاستحواذ على قفل ببساطة من استخدام المقارنة والتبديل لضبط قيمة كلمة futex ذريًا إلى معرف خيط (TID) المستدعي إذا كانت قيمتها السابقة 0. يتطلب تحرير القفل استخدام المقارنة والتبديل لضبط قيمة كلمة futex إلى 0 إذا كانت القيمة السابقة هي TID المتوقع.

إذا تم حيازة فوتكس بالفعل (أي له قيمة غير صفرية)، فيجب على المنتظرين استخدام عمليات FUTEX_LOCK_PI أو FUTEX_LOCK_PI2 لحيازة القفل. إذا كانت هناك خيوط أخرى تنتظر القفل، فسيتم ضبط بت FUTEX_WAITERS في قيمة الفوتكس؛ في هذه الحالة، يجب على مالك القفل استخدام عملية FUTEX_UNLOCK_PI لتحرير القفل.

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

من المهم ملاحظة أن النواة ستحدث قيمة كلمة futex قبل العودة إلى مساحة المستخدم. (يمنع هذا احتمال انتهاء قيمة كلمة futex في حالة غير صالحة، مثل وجود مالك بينما القيمة هي 0، أو وجود منتظرين دون ضبط بت FUTEX_WAITERS).

إذا كان لـ futex ما يقابله من RT-mutex في النواة (أي يوجد منتظرون محبوسون) ومات مالك الـ futex/RT-mutex بشكل غير متوقع، تقوم النواة بتنظيف الـ RT-mutex وتسليمه للمنتظر التالي. وهذا بدوره يتطلب تحديث قيمة مساحة المستخدم وفقًا لذلك. وللإشارة إلى أن هذا مطلوب، تضبط النواة بت FUTEX_OWNER_DIED في كلمة futex مع معرف الخيط للمالك الجديد. يمكن لمساحة المستخدم اكتشاف هذا الموقف عبر وجود بت FUTEX_OWNER_DIED وهي المسؤولة حينئذٍ عن تنظيف الحالة القديمة التي تركها المالك الميت.

يتم تشغيل فوتكسات PI بتحديد إحدى القيم المدرجة أدناه في futex_op. لاحظ أنه يجب استخدام عمليات فوتكس PI كعمليات مزدوجة وهي تخضع لبعض المتطلبات الإضافية:

•

تتقابل العمليات FUTEX_LOCK_PI و FUTEX_LOCK_PI2 و FUTEX_TRYLOCK_PI مع العملية FUTEX_UNLOCK_PI. ويجب ألا تُستدعى FUTEX_UNLOCK_PI إلا على فيوتكس (futex) يمتلكه خيط الاستدعاء، كما هو محدد في سياسة القيمة، وإلا فسينتج الخطأ EPERM.

•

FUTEX_WAIT_REQUEUE_PI يقترن مع FUTEX_CMP_REQUEUE_PI. يجب أن يتم ذلك من فوتكس غير PI إلى فوتكس PI متميز (وإلا ستكون النتيجة الخطأ EINVAL). بالإضافة إلى ذلك، يجب أن يكون val (عدد المنتظرين الذين سيتم إيقاظهم) هو 1 (وإلا ستكون النتيجة الخطأ EINVAL).

عمليات PI futex هي كما يلي:

FUTEX_LOCK_PI (منذ لينكس 2.6.18)

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

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

إذا وجد أكثر من منتظر واحد، يكون إدراج المنتظر في الصف بترتيب تنازلي للأولويات. (للحصول على معلومات حول ترتيب الأولويات، راجع مناقشة سياسات الجدولة SCHED_DEADLINE، و SCHED_FIFO، و SCHED_RR في sched(7)). يرث المالك إما عرض النطاق الترددي للمعالج الخاص بالمنتظر (إذا كان المنتظر مجدولاً تحت سياسة SCHED_DEADLINE) أو أولوية المنتظر (إذا كان المنتظر مجدولاً تحت سياسة SCHED_RR أو SCHED_FIFO). يتبع هذا الميراث سلسلة القفل في حالة القفل المتداخل ويقوم باكتشاف الحصر المتبادل (Deadlock).

توفر المعطاة timeout مهلة لمحاولة القفل. إذا كانت timeout ليست NULL، فإن الهيكل الذي تشير إليه يحدد مهلة مطلقة، تُقاس مقابل ساعة CLOCK_REALTIME. إذا كانت timeout هي NULL، فستُحصر العملية إلى أجل غير مسمى.

تُتجاهل المعطيات uaddr2، و val، و val3.

FUTEX_LOCK_PI2 (منذ لينكس 5.14)

هذه العملية هي نفسها FUTEX_LOCK_PI، باستثناء أن الساعة التي تُقاس بها timeout قابلة للاختيار. مبدئياً، تُقاس المهلة (المطلقة) المحددة في timeout مقابل ساعة CLOCK_MONOTONIC، ولكن إذا تم تحديد علم FUTEX_CLOCK_REALTIME في futex_op، فستُقاس المهلة مقابل ساعة CLOCK_REALTIME.

FUTEX_TRYLOCK_PI (منذ لينكس 2.6.18)

تحاول هذه العملية حيازة القفل عند uaddr. تُستدعى عندما لم تنجح الحيازة الذرية في مساحة المستخدم لأن كلمة الفوتكس لم تكن 0.

نظرًا لأن النواة لديها إمكانية الوصول إلى معلومات حالة أكثر من مساحة المستخدم، فقد تنجح حيازة القفل إذا قامت بها النواة في الحالات التي تحتوي فيها كلمة الفوتكس (أي معلومات الحالة التي يمكن لمساحة المستخدم الوصول إليها) على حالة قديمة (FUTEX_WAITERS و/أو FUTEX_OWNER_DIED). يمكن أن يحدث هذا عند وفاة صاحب الفوتكس. لا تستطيع مساحة المستخدم التعامل مع هذه الحالة بطريقة خالية من التنافس، ولكن يمكن للنواة إصلاح ذلك وحيازة الفوتكس.

تُتجاهل المعطيات uaddr2، و val، و timeout، و val3.

FUTEX_UNLOCK_PI (منذ لينكس 2.6.18)

توقظ هذه العملية المنتظر صاحب الأولوية القصوى الذي ينتظر في FUTEX_LOCK_PI أو FUTEX_LOCK_PI2 على عنوان الفوتكس المقدم بواسطة معطاة uaddr.

يُستدعى هذا عندما لا يمكن تغيير القيمة في مساحة المستخدم عند uaddr ذرياً من TID (للمالك) إلى 0.

تُتجاهل المعطيات uaddr2، و val، و timeout، و val3.

FUTEX_CMP_REQUEUE_PI (منذ لينكس 2.6.31)

هذه العملية هي متغير مدرك لـ PI من FUTEX_CMP_REQUEUE. تعيد وضع المنتظرين المحصورين عبر FUTEX_WAIT_REQUEUE_PI على uaddr من فوتكس مصدر غير PI‏ (uaddr) إلى فوتكس هدف PI‏ (uaddr2).

كما هو الحال مع FUTEX_CMP_REQUEUE، توقظ هذه العملية بحد أقصى val من المنتظرين الذين ينتظرون على الفوتكس عند uaddr. ومع ذلك، بالنسبة لـ FUTEX_CMP_REQUEUE_PI، يجب أن يكون val هو 1 (بما أن الهدف الرئيس هو تجنب القطيع الهائج). يُحذف المنتظرون المتبقون من صف انتظار فوتكس المصدر عند uaddr ويُضافون إلى صف انتظار فوتكس الهدف عند uaddr2.

تخدم المعطيات val2 و val3 نفس الأغراض كما في FUTEX_CMP_REQUEUE.

FUTEX_WAIT_REQUEUE_PI (منذ لينكس 2.6.31)

ينتظر على futex غير مرتبط بوراثة الأولوية (non-PI) عند uaddr ومن المحتمل إعادة وضعه في الطابور (عبر عملية FUTEX_CMP_REQUEUE_PI في مهمة أخرى) على futex مرتبط بوراثة الأولوية (PI) عند uaddr2. عملية الانتظار على uaddr هي نفسها في FUTEX_WAIT.

يمكن إزالة المنتظر من الانتظار على uaddr دون إعادة وضعه في الطابور على uaddr2 عبر عملية FUTEX_WAKE في مهمة أخرى. وفي هذه الحالة، تفشل عملية FUTEX_WAIT_REQUEUE_PI مع الخطأ EAGAIN.

إذا كانت timeout ليست NULL، فإن الهيكل الذي تشير إليه يحدد مهلة مطلقة لعملية الانتظار. إذا كانت timeout هي NULL، يمكن حصر العملية إلى أجل غير مسمى.

يُتجاهل المعطى val3.

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

مصدر البرنامج¶

/* futex_demo.c


   Usage: futex_demo [nloops]


                    (Default: 5)


   Demonstrate the use of futexes in a program where parent and child


   use a pair of futexes located inside a shared anonymous mapping to


   synchronize access to a shared resource: the terminal. The two


   processes each write 'num-loops' messages to the terminal and employ


   a synchronization protocol that ensures that they alternate in


   writing messages.
*/
#define _GNU_SOURCE
#include <err.h>
#include <errno.h>
#include <linux/futex.h>
#include <stdatomic.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/syscall.h>
#include <sys/time.h>
#include <sys/wait.h>
#include <unistd.h>
static uint32_t *futex1, *futex2, *iaddr;
static int
futex(uint32_t *uaddr, int futex_op, uint32_t val,


      const struct timespec *timeout, uint32_t *uaddr2, uint32_t val3)
{


    return syscall(SYS_futex, uaddr, futex_op, val,


                   timeout, uaddr2, val3);
}
/* Acquire the futex pointed to by 'futexp': wait for its value to


   become 1, and then set the value to 0. */
static void
fwait(uint32_t *futexp)
{


    long            s;


    const uint32_t  one = 1;


    /* atomic_compare_exchange_strong(ptr, oldval, newval)


       atomically performs the equivalent of:


           if (*ptr == *oldval)


               *ptr = newval;


       It returns true if the test yielded true and *ptr was updated. */


    while (1) {


        /* Is the futex available? */


        if (atomic_compare_exchange_strong(futexp, &one, 0))


            break;      /* Yes */


        /* Futex is not available; wait. */


        s = futex(futexp, FUTEX_WAIT, 0, NULL, NULL, 0);


        if (s == -1 && errno != EAGAIN)


            err(EXIT_FAILURE, "futex-FUTEX_WAIT");


    }
}
/* Release the futex pointed to by 'futexp': if the futex currently


   has the value 0, set its value to 1 and then wake any futex waiters,


   so that if the peer is blocked in fwait(), it can proceed. */
static void
fpost(uint32_t *futexp)
{


    long            s;


    const uint32_t  zero = 0;


    /* atomic_compare_exchange_strong() was described


       in comments above. */


    if (atomic_compare_exchange_strong(futexp, &zero, 1)) {


        s = futex(futexp, FUTEX_WAKE, 1, NULL, NULL, 0);


        if (s  == -1)


            err(EXIT_FAILURE, "futex-FUTEX_WAKE");


    }
}
int
main(int argc, char *argv[])
{


    pid_t         childPid;


    unsigned int  nloops;


    setbuf(stdout, NULL);


    nloops = (argc > 1) ? atoi(argv[1]) : 5;


    /* Create a shared anonymous mapping that will hold the futexes.


       Since the futexes are being shared between processes, we


       subsequently use the "shared" futex operations (i.e., not the


       ones suffixed "_PRIVATE"). */


    iaddr = mmap(NULL, sizeof(*iaddr) * 2, PROT_READ | PROT_WRITE,


                 MAP_ANONYMOUS | MAP_SHARED, -1, 0);


    if (iaddr == MAP_FAILED)


        err(EXIT_FAILURE, "mmap");


    futex1 = &iaddr[0];


    futex2 = &iaddr[1];


    *futex1 = 0;        /* State: unavailable */


    *futex2 = 1;        /* State: available */


    /* Create a child process that inherits the shared anonymous


       mapping. */


    childPid = fork();


    if (childPid == -1)


        err(EXIT_FAILURE, "fork");


    if (childPid == 0) {        /* Child */


        for (unsigned int j = 0; j < nloops; j++) {


            fwait(futex1);


            printf("Child  (%jd) %u\n", (intmax_t) getpid(), j);


            fpost(futex2);


        }


        exit(EXIT_SUCCESS);


    }


    /* Parent falls through to here. */


    for (unsigned int j = 0; j < nloops; j++) {


        fwait(futex2);


        printf("Parent (%jd) %u\n", (intmax_t) getpid(), j);


        fpost(futex1);


    }


    wait(NULL);


    exit(EXIT_SUCCESS);
}