- بواسطة x32x01 ||
لما يكون عندك كذا Task (أو كذا Goroutine في لغة Go) شغالين في نفس الوقت وبيحاولوا يوصلوا لنفس الـ Data.
النتيجة النهائية مش بتعتمد على الكود بتاعك بس، لكن بتعتمد على مين اللي هيوصل للبيانات ويكتب عليها الأول.
دي bug اسمها Data Race، وغالبًا بتكون صعبة جدًا إنك تكتشفها، لأنها ممكن ما تظهرش غير لما البرنامج يشتغل في بيئة (Production) لفترة طويلة وعلي كميه داتا كبيرة.
مثال بـ Golang
بص على الكود ده، اللي بيزود عداد 1000 مرة تاني صورة
هنا الـ counter المفروض يوصل لـ 1000، لكن النتيجة هتكون أقل من كده غالبًا. عشان عملية counter++ مش خطوة واحدة، دي 3 خطوات
قراءة القيمة الحالية للعداد.
زيادة القيمة دي بواحد.
كتابة القيمة الجديدة.
لو فيه اتنين Goroutine دخلوا في نفس الوقت، ممكن واحد يقرأ قيمة العداد، والثاني يقرأ نفس القيمة، وكل واحد يكتب القيمة اللي حسبها، وساعتها بنخسر زيادة واحدة على الأقل.
الحل الصح: استخدم Mutex
عشان نضمن إن كل Goroutine يخلص شغله على العداد قبل ما حد تاني يتدخل، بنستخدم حاجة اسمها Mutex (اختصار لـ Mutual Exclusion).
شوف كده الكود بعد التصحيح , ثالث صورة
لما تستخدم mu.Lock() و mu.Unlock()، بنضمن إن الـ Goroutine الوحيد اللي معاه المفتاح هو اللي يقدر يغير قيمة الـ counter، وبكده النتيجة هتكون 1000 دايماً.
فيه نوع تاني من الـ Race Condition مش بسبب كود مكتوب غلط، لكن بسبب طريقة عمل نظام التشغيل (OS) والبروسيسور (CPU).
لما الـ OS بيلاقي Task أهم محتاجة تتنفذ، ممكن يوقف الـ Thread اللي بيشغل الـ Goroutine بتاعك في أي لحظة. وقتها، بيعمل حاجة اسمها Context Switch، يعني بيحفظ حالة الـ Goroutine بتاعك (زي لقطة Snapshot كده) عشان يرجع يكملها بعدين.
المشكلة بتحصل لو فيه Thread تاني في نفس الوقت كان بيعدل على نفس الـ Data اللي الأول كان هيعدل عليها. لما الأول يرجع من الـ Snapshot، بيكتب فوق القيمة الجديدة اللي اتغيرت، وبكده بنخسر التعديل.
عشان كده، حتى لو الكود بتاعك يبان إنه "صح" بالمنطق، لازم تستخدم أدوات زي Mutex عشان تضمن إن العمليات اللي على البيانات المشتركة بتتعمل بشكل آمن، بغض النظر عن طريقة عمل نظام التشغيل.
النتيجة النهائية مش بتعتمد على الكود بتاعك بس، لكن بتعتمد على مين اللي هيوصل للبيانات ويكتب عليها الأول.
دي bug اسمها Data Race، وغالبًا بتكون صعبة جدًا إنك تكتشفها، لأنها ممكن ما تظهرش غير لما البرنامج يشتغل في بيئة (Production) لفترة طويلة وعلي كميه داتا كبيرة.
مثال بـ Golang
بص على الكود ده، اللي بيزود عداد 1000 مرة تاني صورة
هنا الـ counter المفروض يوصل لـ 1000، لكن النتيجة هتكون أقل من كده غالبًا. عشان عملية counter++ مش خطوة واحدة، دي 3 خطوات
قراءة القيمة الحالية للعداد.
زيادة القيمة دي بواحد.
كتابة القيمة الجديدة.
لو فيه اتنين Goroutine دخلوا في نفس الوقت، ممكن واحد يقرأ قيمة العداد، والثاني يقرأ نفس القيمة، وكل واحد يكتب القيمة اللي حسبها، وساعتها بنخسر زيادة واحدة على الأقل.
الحل الصح: استخدم Mutex
عشان نضمن إن كل Goroutine يخلص شغله على العداد قبل ما حد تاني يتدخل، بنستخدم حاجة اسمها Mutex (اختصار لـ Mutual Exclusion).
شوف كده الكود بعد التصحيح , ثالث صورة
لما تستخدم mu.Lock() و mu.Unlock()، بنضمن إن الـ Goroutine الوحيد اللي معاه المفتاح هو اللي يقدر يغير قيمة الـ counter، وبكده النتيجة هتكون 1000 دايماً.
فيه نوع تاني من الـ Race Condition مش بسبب كود مكتوب غلط، لكن بسبب طريقة عمل نظام التشغيل (OS) والبروسيسور (CPU).
لما الـ OS بيلاقي Task أهم محتاجة تتنفذ، ممكن يوقف الـ Thread اللي بيشغل الـ Goroutine بتاعك في أي لحظة. وقتها، بيعمل حاجة اسمها Context Switch، يعني بيحفظ حالة الـ Goroutine بتاعك (زي لقطة Snapshot كده) عشان يرجع يكملها بعدين.
المشكلة بتحصل لو فيه Thread تاني في نفس الوقت كان بيعدل على نفس الـ Data اللي الأول كان هيعدل عليها. لما الأول يرجع من الـ Snapshot، بيكتب فوق القيمة الجديدة اللي اتغيرت، وبكده بنخسر التعديل.
عشان كده، حتى لو الكود بتاعك يبان إنه "صح" بالمنطق، لازم تستخدم أدوات زي Mutex عشان تضمن إن العمليات اللي على البيانات المشتركة بتتعمل بشكل آمن، بغض النظر عن طريقة عمل نظام التشغيل.