پراسس به عنوان ی مفهوم کلیدی توی سیستم‌عامل ها، نماینگر فعالیت‌هاییه که توی پس‌زمینه در حال اجرا هستن، وقتی ی برنامه و فعالیت رو شروع میکنین، سیستم‌عامل ی پراسس واسش ایجاد میکنه که این پراسس شامل تمامی موارد موردنیاز اجرا شدن برنامه میشه، مثلا سورس‌کد، داده‌ها، وضعیت اجرایی و..
فرض کنین در حال کار با سیستم هستین و برنامه‌ی VSCODE رو باز و شروع به کد زدن میکنین، وقتی این برنامه رو باز میکنین سیستم عامل ی درخواست مبتنی بر ایجاد پراسس جدید ارسال میکنه و پراسس ایجاد میشه، در ادامه با نحوه ایجاد شدنش مفصل تر آشنا میشیم.

توی ی حالت کلی به شش حالت و عملکرد تقسیم میشن :
ایجاد و ساخته شدن / CREATION : بالاتر گفتیم که با باز و ران کردن ی برنامه، پراسسی ایجاد میشه، اگه بخوایم دقیق تر بیان کنیم، باید گفت ی پراسس زمانی ایجاد میشه که برنامه به حافظه بارگذاری بشه، این مرحله  شامل تخصیص منابع و بلوک کنترل میشه.

انتقال بین استیت ها : پراسس ها میتونن حالت های مختلفی داشته و توی این حالت ها جابه‌جا بشن ( درحال ایجاد ، درحالت تخصیص CPU، درحال اجرا توسط CPU، منتظر ی رویداد مثلا ورودی خروجی و یا توی حالت اتمام شده خودشون باشن ).

مدیریت منابع : هر پراسسی نیاز به منابعی مثل CPU و یا رم داره، سیستم‌عامل ها توی زمان اجرای پراسس‌ها این منابع رو مدیریت میکنن که از تداخل نداشتن و پیدانکردنشون اطمینان حاصل کنن.

زمان‌بندی : سیستم‌عامل واسه اینکه تعیین کنه کدوم پراسس در حال حاظر اجرا بشه از الگوریتم خاصی استفاده و پراسس ها رو صف بندی میکنه.

ارتباط بین پراسس‌ها : پراسس ها معمولا نیاز دارن که باهم در ارتباط باشن و با ارتباط باهمدیگه کار میکنن، این ارتباط معمولا از طریق ارسال پیام توی حافظه مشترک انجام میشه.

پایان پراسس : توی حالت عادی، وقتی پراسس کار خودش رو تموم میکنه به حالت پایان یافته منتقل میشه و سیستم عامل اقدام به پاکسازی برخی از اجزا مثل حافظه RAM و یا بلوک کنترل پراسس میکنه، البته باید اشاره کنم که همیشه اوضاع به همین خوب و خوشی نیست ممکنه مشکلاتی ایجاد بشه و پراسس تغیر کنه، توی ادامه پست بیشتر آشنا میشیم با این مورد.

هر پراسسی که توسط سیستم‌عامل ایجاد میشه بطور خاص دارای مشخصات خاصیه :

استفاده از رم / RAM : هر پراسسی مقداری از رم رو به خودش اختصاص میده که خودش به دو نوع اصلی تقسیم میشه ( استک : واسه ذخیره‌سازی متغیر و داده های محلی، هیپ : واسه ذخیره‌سازی اشیاء و داده‌های داینامیک )

استفاده از سی‌پی‌یو / CPU : هر پراسس به نوبت بسته به نوع و هسته CPU، از CPU استفاده میکنه، توی پست های قبلی با CPUها آشنا شدیم، توی کامپیوتر های جدید هر پراسس با سوئیچینگ با ترتیب از CPU استفاده میکنه.

داشتن شناسه پراسس / PID : هر پراسسی واسه شناسایی شدن توی سیستم دارای ی PID یونیکیه.

قبل اینکه حالات پراسس رو بیان کنیم باید با دوتا مسئله آشنا بشیم، یکی پراسس والد و یکی پراسس فرزند :

پراسس والد : منظور از پراسس والد همون پراسس اصلی و درواقع اون برنامه‌ایه که اجرا شده
پراسس فرزند : وقتی پراسس والد به نوبه‌خودش چندتا پراسس دیگه‌ای رو شروع‌ کنه و انجام بده، به هر یکی از اون پراسس ها به اصطلاح "پراسس فرزند" میگیم، شاید توی نگاه اول یکم پیچیده بیاد ولی اینطور نیست، مثال زیر رو ببینین :
فرض کنین همون برنامه VSCODE رو ران کردیم، در اینجا خود برنامه VSCODE به عنوان پراسس والد شناخته میشه و وقتی ی فایل مثلا پایتونی رو داخلش باز میکنیم، پراسس والد ی پراسس فرزند واسه اون فایل پایتونی ایجاد میکنه.

توی حالت عادی، پراسس ها رو از نظر وضعیت میتونیم به دو دسته اصلی تقسیم کنیم، پراسس های یتیم و پراسس های زامبی!! :

پراسس های یتیم : این پراسس ها وقتی ایجاد میشن که پراسس والد قبل از تموم شدن کارش، تموم میشه، توی همچین موقعیتی معمولا سیستم عامل این پراسس رو به عنوان "INIT" نامگذاری میکنه که کمک مدیریتی ایجاد بشه ( تصور کنین ی کودک وجود داره که باباش تنهاش گذاشته 🐱 ) .
پراسس زامبی : وقتی به پراسسی به اصطلاح پراسس زامبی میگیم که کارش تموم شده ولی هنوز اطلاعاتش توسط والد خونده نشده 👀، معمولا به این پراسس، پراسس مرده هم میگن! درکل بدونین که تا وقتی توسط والد خونده نشه موجب مصرف منابعه و توی حالت انتظار قرار داره، پس از این به بعد مراقب باشین که پراسس والد رو KILL نکنین چون ممکنه پراسس های فرزند یا نابود و یا به زامبی تبدیل بشن، شما که ادم‌کُش نیستید نه؟! ( شوخی 😆 )

توی پست‌های قبلی با پراسس ها آشنا شدیم و میدونیم که پراسس نمونه‌ای از برنامه درحال اجرا شامل کد های برنامه، فعالیت کنونی و منابع مصرفی هست و با ایزوله بودن نسبت به سایر پراسس ها، توی فضای حافظه خودش کار میکنه. نخ کوچیکترین واحد اجرایی داخل پراسسه که به عنوان پراسس سبک هم شناخته میشه، پس با این حال داخل هر پراسسی ممکنه چندین نخ وجود داشته باشه که با استفاده از منابع مشترک، اشتراک‌گذاری داده ها رو بطور موثری فراهم میکنه. درواقع میشه این نتیجه رو گرفت که نخ همون پراسسه منتها بهینه‌تر!

سبک بودن : نخ ها از پراسس سبک تر هستن به این صورت که واسه ایجاد یا مدیرتشون به هزینه کمتری نیازه.
حافظه مشترک : نخ ها توی ی پراسس از منابع مشترکی استفاده میکنن که همین باعث فراهم آوردن ارتباط سریعتری میشه، درواقع با تعریف شدن ی استک جدا ریجستر میشه.
هم‌زمانی : نخ ها این امکان که برنامه‌ای با مقیاس پذیری بالاتر و کارآمد رو توسعه بدیم به ارمغان میاره، البته مدیریت هم‌زمانی نخ باید صورت بگیره که خودش بحث مفصلی داره.

اپلیکیشن پست قبلی رو دوباره به خاطر بیارین، فرض کنین همزمان ١٠٠٠ نفر از این اپلیکیشن استفاده کنن و وب‌سرور اپلیکیشن حالت پراسس داشته باشه، یعنی واسه هر نفری که از این اپلیکیشن استفاده میکنه و ریکوئستی به وب‌سرور ارسال میشه، ی پراسس ران بشه و وب‌سرور واسه‌ی این پراسس مقداری منابع مثل رم، استک، دیتا و غیره در نظر بگیره، عملا اگه ساختار به این صورت باشه، با استفاده همزمان ١٠٠٠ نفری از اپلیکیشن، وب‌سرور داون میشه!🤯 اینجاس که میگیم چه کاریه آخه، بجای هر بار ران کردن ی پراسس، بعد از دریافت هر رکوئست، ی ترد جدید ایجاد میکنیم، یعنی ی پراسس واحد یا والد درنظر گرفته میشه ( اینجا همون وب‌سرور پراسس والد حساب میشه ) و با هر بار دریافت رکوئست، نخ یا ترد هایی ران میشن، به بیان ساده تر ی استک جدید تعریف و ریجستر میشه و با هر ترد جدیدی، مجدد دیتای جدید نوشته نمیشه و بدون افت افت کارایی یا کرش به تمامی ریکوست ها پاسخ میدیم!🤤

وقتی حرف از Sync بودن کدمون میزنیم درواقع منظور اصلیمون ترتیب اجرای کده که به اصطلاح بصورت Blocking اجرا میشن؛ یعنی به ترتیب لاین های کد کدمون اجرا میشه و تا وقتی پروسه حال حاظر تکمیل نشه مابقی کد هم اجرا نمیشن. Sync بودن اجرای کد رو قابل پیش‌بینی میکنه و به هر صورتی که کد رو نوشته باشیم، دقیقا به همون صورت و ترتیب هم اجرا میشن.

شاید با خودتون بگین که Async خلاف روند Sync عمل میکنه، اما جا داره که بگم اینطور نیست!! Async و Sync مکمل هم هستن و در واقع Asynchronous بودن کد باعث متفاوت بودن ترتیب اجرا با ترتیب کد میشه، یعنی منتظر تموم شدن کد قبلی نمیمونه و طی زمانی که کد قبلی اجرا میشه به سایر اجزای کد میپردازه (کارکرد اف‌لود). کد های Async ممکنه که به حالت موازی صورت بگیرن و باعث اجرای پارالل و یا غیر موازی و موجب همروندی بشن. معمولا توی زبان هایی که از Asynchronous پشتیبانی میکنن با کلید های Async و Await مشخص و نوشته میشن.

اپلیکیشن مثال های قبلی رو دوباره متصور بشین، فرض کنین این اپلیکیشن از چندین فانکشن تشکیل شده که هر فانکشن کار و عملیات خاصی رو انجام میدن، این وسط ی فانکشن تحت عنوان ارسال درخواست به API داریم که مسئولیت ارسال رکوئست به API و برگردوندن خروجی رو داره و ممکنه پاسخ از سمت API کمی طول بکشه، اگه این فانکشن رو بصورت Sync بنویسیم و اون رو کال کنیم، تا زمانی که فرایند و تمامی بلوک این فانکشن کامل انجام نشه مابقی فانکشن و کدها هم اجرا نمیشن و اپلیکیشن منتظر اتمام کار این فانکشن میمونه، ولی اگه صورت Async این کد رو بنویسیم، اپلیکیشن ما منتظر تکمیل شدن کارکرد این فانکشن نمیمونه و سایر فانکشن ها و کد به حالت عادی خودشون ادامه میدن 🥺

زبان های مختلف دارای قابلیت Async معمولا یا از موارد زیر یا ترکیب و تلفیقشون واسه مدل Asynchronous استفاده میکنن :
1️⃣- استفاده از پراسس ها مبتنی به حافظه غیر اشتراکی که قبلا باهاشون آشنا شدیم.
2️⃣- با استفاده از Event ها، EventLoop و یا مابقی الگوریتم های مبتنی بر این‌ها
3️⃣- با استفاده از ترد با این تفاوت که از فضای اشتراکی استفاده میکنن (با تردم قبلا بصورت مفصل آشنا شدیم)

بعضی از زبان‌ها مثل پایتون و جاوااسکریپت از Async پشتیبانی و بعضی هم مثل PHP، C، Go و.. هم پشتیبانی نمیکنن که البته با مالتی‌تردینگ و مالتی‌پراسسینگ میشه این قابلیت رو پیاده سازی کرد.

نه، خیلی اوقات نیازی به Async بودن کدمون نیست و Async نوشتن فانکشن و مابقی اجزای کد بیخودیه مثل این مورد. توی حالت کلی داخل مواقعی که با عملیات های IO Bound طرفیم باید کدمون حالت Async داشته باشه مثل مواقعی که با ارسال رکوئست های پیاپی با تاخیر زیاد یا مواقعی که با ورودی و خروجی زیادی و.. سر و کار داریم

🔘توی کد های Async ترتیب اجرا، نحوه دسترسی هر جریان و قسمت اجرایی به داده‌ها و مدت زمان صرف شده واسه رسیدن به نتیجه مشخص نیست.

🟢مدیریت استیت‌منیجمنت توی کد های Async ممکنه چالش برانگیز و نیازمند به الگوی مناسب داشته باشه.

🔘نمیتونیم هیچ تضمینی واسه سریع‌تر شدن کد با Async کردنش ارائه بدیم (بستگی به فرایند داره)

🟣توی کد های Async مدیریت منابع خیلی مهمه، فرض کنید بصورت Async به دیتابیسی اتصال داریم، اگه مدیریت درستی انجام نشه منجر به Memory Leek میشه!