در بخش قبلی، مروری کلی بر مفاهیم اصلی برنامه نویسی موازی، از جمله شرایط و نکات استفاده از آن را بررسی کردیم. در انتهای بخش اول عنوان کردیم که در روند برنامه نویسی موازی، اگر دو یا چند Thread به طور مشترک به داده‌ای دسترسی داشته باشند، امکان بروز Race condition وجود خواهد داشت. پس باید کد خود را Thread Safe کنیم. می‌توان برای کنترل رفتارهای عجیب اشیاء در محیط‌های Multi Thread، عنوان Thread Safety را بکار برد.
به طور کلی ۴ روش در #C برای ایجاد Thread Safety وجود دارند:
1- Lock/Monitor
این دو روش یکسان هستند و مانند هم عمل می‌کنند. در واقع در ابتدا روش Monitor وجود داشته و بعد روش lock برای کوتاهی syntax، به صورت بلاکی به #C افزوده شده‌است. این روش تنهای بر روی Threadهای داخلی App Domain کنترل دارد (اجازه ورود یک Thread) و نمی‌تواند بر روی Threadهای خارج از این حوزه در محیط‌های Multi Thread محدودیتی اعمال نماید. منظور از Threadهای داخلی، Thread هایی هستند که داخل Application ما ایجاد شده‌اند.
به تکه کد زیر توجه کنید:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Threading;
class Program
{
static int a = 0;
static int b = 0;
static Random random = new Random();
static void Main(string[] args)
{
Thread obj = new Thread(Division);
obj.Start();
Division();
}
static void Division()
{
for (int i = 0; i <= 500; i++)
{
try
{
//Choosing random numbers between 1 to 5
a = random.Next(1, 10);
b = random.Next(1, 10);
//Dividing
double ans = a / b;
//Reset Variables
a = 0;
b = 0;
Console.WriteLine("Answer : {0} --> {1}", i, ans);
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
}
} همانطور که در کد بالا ملاحظه می‌کنید، متد Division به صورت Thread Safe پیاده سازی نشده‌است! اما مشکل کجاست!؟
با برسی این متد و عملکرد آن متوجه می‌شویم که این متد در یک چرخه‌ی تکرار ۵۰۰ مرتبه‌ای، دو عدد تصادفی را در بازه‌ی ۱ تا ۱۰، انتخاب کرده و آنها را بر هم تقسیم و متغیر‌های تصادفی را با مقدار ۰ پر می‌کند. همین عمل Reset Variable در این متد، باعث بروز خطا در محیط Multi Thread خواهد شد. بدین صورت که اگر این متد مانند مثال بالا توسط دو Thread مجزا فراخوانی شود، یکبار توسط New Thread و بلافاصله در Thread اصلی Application، احتمال این وجود خواهد داشت که در Thread دوم، بعد از انتخاب دو مقدار تصادفی و درست قبل از عملیات تقسیم، به طور همزمان Thread اول عملیات Reset Variable را انجام دهد که باعث بروز خطای تقسیم بر ۰ در Thread دوم می‌شود. این همان مشکلی است که گاها یافتن آن از طریق Debug بسیار دشوار خواهد بود.
اما با تغییر کد به شکل زیر
class Program
{
static int a = 0;
static int b = 0;
static Random random = new Random();
static readonly object _object = new object();
static void Main(string[] args)
{
Thread obj = new Thread(Division);
obj.Start();
Division();
}
static void Division()
{
for (int i = 0; i <= 500; i++)
{
try
{
Monitor.Enter(_object);
//Choosing random numbers between 1 to 5
a = random.Next(1, 10);
b = random.Next(1, 10);
//Dividing
double ans = a / b;
//Reset Variables
a = 0;
b = 0;
Console.WriteLine("Answer : {0} --> {1}", i, ans);
Monitor.Exit(_object);
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
}
} مادامی که یک Thread در حالت انتخاب اعداد تصادفی تا تقسیم و اعلام نتیجه می‌باشد، به Threadهای داخلی دیگر، اجازه‌ی ورود به این بخش که تحت کنترل Monitor می‌باشد داده نخواهد شد. همانطور که گفته شده، بازه‌ی تحت کنترل مانیتور میتواند با بلاک Lock(object) جایگزین شود. شیء object یک شیء مشترک (static) میان تمام اشیاء است برای کنترل ورود Threadها و قفل گزاری مشترک بین این اشیاء.
2- Mutex:
این نوع قفل گزاری به منظور محافظت منابع مشترک برای جلوگیری از ورود Threadهای بیرونی استفاده می‌شود. منظور از Threadهای بیرونی Threadهای یک کامپیوتر است. همچنین می‌توان از Mutex بجای lock نیز استفاده کرد؛ اما به دلیل هدف کاری Mutex، باید هزینه‌ی بیشتری (تقریبا 50 برابر کندتر از Lock) پرداخت کرد.
static void Main()
{
using (var mutex = new Mutex (false, "dotnettips.info Demo"))
{
if (!mutex.WaitOne (TimeSpan.FromSeconds (3), false))
{
Console.WriteLine ("Another app instance is running. Bye!");
return;
}
RunProgram();
}
}
static void RunProgram()
{
Console.WriteLine ("Running. Press Enter to exit");
Console.ReadLine();
} Mutex دارای دو متد مهم است :
۱- WaiteOne : شروع Blocking با این متد خواهد بود و اگر بتواند عملیات blocking را انجام دهد مقدار True را باز می‌گرداند. این متد دارای دو ورودی دیگر نیز هست که در مقالات بعدی به طور مفصل به آنها اشاره خواهد شد. اما بطور خلاصه می‌توان اینگونه عنوان نمود که یک پارامتر زمان وجود دارد که مدت زمان انتظار برای Blocking را مشخص می‌کند و پارامتر Boolean دیگری که در حالت synchronization مورد استفاده قرار می‌گیرد و خروج و یا عدم خروج از دامنه synchronization را مشخص می‌کند.
۲- ReleaseMutex : شروع آزاد سازی انحصار، با این متد انجام می‌شود.
هیچگاه نباید یک Mutex را در کد رها کرد؛ زیرا باعث به‌وجود آمدن خطاهایی در کد خواهد شد. روش‌هایی برای رها سازی وجود دارد مانند Dispose کردن Mutex و یا استفاده از متد ReleaseMutex. قبل از خروج از کد باید دقت داشت در بخش هایی از کد که از این نوع قفل گزاری استفاده شده‌است، حتما باید مکانیسم‌های Exception Handling و یا Disposing را برای مدیریت Mutex ایجاد شده اعمال کرد.
3 -Semaphore
یک نسخه پیشرفته‌تر از Mutex است که میتواند برای Threadهای داخلی و یا خارجی استفاده شود و روی آنها اعمال محدودیت کند. همچنین میتواند اجازه‌ی ورود یک تا چند Thread را به بخشی از کد، برای محافظت از منابع بدهد. Semaphore نیز مانند Mutex دارای متدهای Wait و Release است. یک Semaphore با ظرفیت ورود یک Thread در لحظه همان Mutex است. همچنین از Semaphoreها می‌توان در متدهای Async نیز استفاده کرد.
4- SemaphoreSlim
در واقع یک نسخه‌ی پیشرفته از Monitor و یک نسخه‌ی سبک وزن از Semaphore است و به همان شکل به شما اجازه‌ی محدودیت گزاری فقط بر روی Threadهای داخلی را می‌دهد. اما بجای اجازه‌ی ورود فقط یک Thread، به شما این امکان را می‌دهد که اجازه‌ی ورود همزمان یک یا چند Thread را به انتخاب خود بدهید.
هزینه‌ی اعمال محدودیت (قفل گزاری) روی Thread ها
به طور کل هزینه‌ی قفل گزاری بر روی Threadها بالاست. اما در صورت نیاز باید انتخاب درستی از بین موارد عنوان شده را انتخاب نمود. lock/Monitor و SemaphoreSlim دارای کمترین هزینه و Mutex و Semaphore دارای بیشترین هزینه و سربار هستند. اگر در Applicationهای بزرگ از Mutex و Semaphore به درستی استفاده نشود، به جد باعث کندی خواهد شد.
در بخش بعدی مقاله، Double-checked locking را مورد بررسی قرار خواهیم داد.
