المعطيات¶

يشير المعطى uaddr إلى كلمة futex. في جميع المنصات، تكون الـ futexes أعدادًا صحيحة بحجم أربعة بايتات ويجب أن تكون محاذية على حدود أربعة بايتات. تُحدد العملية المراد تنفيذها على الـ futex في المعطى op.

عمليات Futex¶

يتكون المعطى op من جزأين: أمر يحدد العملية المراد تنفيذها، مدمجًا عبر عملية OR بتية مع خيار واحد أو أكثر يعدل سلوك العملية. الخيارات التي قد تُضمن في 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(2const)، وFUTEX_WAIT_REQUEUE_PI(2const)، و(منذ لينكس 4.5) FUTEX_WAIT(2const)، و(منذ لينكس 5.14) FUTEX_LOCK_PI2(2const).

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

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

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

FUTEX_WAIT(2const)

FUTEX_WAKE(2const)

FUTEX_FD(2const)

FUTEX_REQUEUE(2const)

FUTEX_CMP_REQUEUE(2const)

FUTEX_WAKE_OP(2const)

FUTEX_WAIT_BITSET(2const)

FUTEX_WAKE_BITSET(2const)

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 مستحوذًا عليه بالفعل (أي يملك قيمة غير صفرية)، يجب على المنتظرين توظيف عمليات FUTEX_LOCK_PI(2const) أو FUTEX_LOCK_PI2(2const) للاستحواذ على القفل. إذا كانت هناك خيوط أخرى تنتظر القفل، يُضبط بت FUTEX_WAITERS في قيمة الـ futex؛ في هذه الحالة، يجب على مالك القفل توظيف عملية FUTEX_UNLOCK_PI(2const) لتحرير القفل.

في الحالات التي يُجبر فيها المستدعون على الدخول إلى النواة (أي يُطلب منهم إجراء استدعاء 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 futexes عبر تحديد إحدى القيم المدرجة أدناه في op. لاحظ أنه يجب استخدام عمليات PI futex كعمليات مزدوجة وتخضع لبعض المتطلبات الإضافية:

•

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

•

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

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

FUTEX_LOCK_PI(2const)

FUTEX_LOCK_PI2(2const)

FUTEX_TRYLOCK_PI(2const)

FUTEX_UNLOCK_PI(2const)

FUTEX_CMP_REQUEUE_PI(2const)

FUTEX_WAIT_REQUEUE_PI(2const)

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

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

/* futex_demo.c


   الاستخدام: futex_demo [nloops]


                    (المبدئي: 5)


   توضيح استخدام الـ futexes في برنامج حيث يستخدم الأب والابن


   زوجًا من الـ futexes الموجودة داخل تخطيط مجهول مشترك لـ


   مزامنة الوصول إلى مورد مشترك: الطرفية. تكتب كل واحدة من


   العمليتين رسائل بـ 'num-loops' إلى الطرفية وتوظف


   بروتوكول مزامنة يضمن تبادلهما في


   كتابة الرسائل.
*/
#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 op, uint32_t val,


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


    return syscall(SYS_futex, uaddr, op, val,


                   timeout, uaddr2, val3);
}
/* الاستحواذ على الـ futex الذي يشير إليه 'futexp': الانتظار حتى تصبح قيمته


   1، ثم ضبط القيمة إلى 0.  */
static void
fwait(uint32_t *futexp)
{


    long            s;


    const uint32_t  one = 1;


    /* atomic_compare_exchange_strong(ptr, oldval, newval)


       ينفذ ذريًا ما يعادل:


           if (*ptr == *oldval)


               *ptr = newval;


       يعيد true إذا كان الاختبار صحيحًا وحُدث *ptr.  */


    for (;;) {


        /* هل الـ futex متاح؟ */


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


            break;      /* نعم */


        /* الـ futex غير متاح؛ انتظر.  */


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


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


            err(EXIT_FAILURE, "futex-FUTEX_WAIT");


    }
}
/* تحرير الـ futex الذي يشير إليه 'futexp': إذا كانت قيمة الـ futex حاليًا


   0، فاضبط قيمته إلى 1 ثم أيقظ أي منتظرين لـ futex،


   بحيث إذا كان النظير محبوسًا في fwait()، يمكنه المتابعة.  */
static void
fpost(uint32_t *futexp)
{


    long            s;


    const uint32_t  zero = 0;


    /* atomic_compare_exchange_strong() شُرحت


       في التعليقات أعلاه.  */


    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;


    /* إنشاء تخطيط مجهول مشترك سيحتوي على الـ futexes.


       بما أن الـ futexes ستُشارك بين العمليات، فسنستخدم


       لاحقًا عمليات الـ futex "المشتركة" (أي ليس


       التي تنتهي بـ "_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;        /* الحالة: غير متاح */


    *futex2 = 1;        /* الحالة: متاح */


    /* إنشاء عملية ابن ترث التخطيط المجهول المشترك.


       */


    childPid = fork();


    if (childPid == -1)


        err(EXIT_FAILURE, "fork");


    if (childPid == 0) {        /* الابن */


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


            fwait(futex1);


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


            fpost(futex2);


        }


        exit(EXIT_SUCCESS);


    }


    /* الأب يصل إلى هنا.  */


    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);
}