توی پست اول متوجه شدیم که وقتی می گیم یه کد، Asynchronous کار می کند ، منظورمون چیه. حالا میریم سراغ این که آیا Asynchronous همون Multithreading ه یا نه؟
خب جواب این سوال، خیر است :) یعنی کدی که Asynchronous نوشته شده است، هرگز مثل کدی که از multithreading استفاده می کند، نیست.
توی مبحث multithreading، همانطور که از اسمش پیداست کارها روی thread های کاملا مجزا انجام می شوند به صورتی که هیچ گونه ارتباطی بین این thread ها وجود ندارد. اما توی مبحث Asynchronous Programming یه نقاطی هست که thread ها می توانند از آنجا کار باقی مونده رو به دست بگیرند و ادامه ش بدهند و یا این که یه کار رو رها کنند و برن سراغ یه کار دیگه. (توی مقالات بعدی خیلی مفصل این بخش رو باز می کنیم!)
اگر مقاله قبلی رو خونده باشید، الان با این مثال من کاملا متوجه میشید که قضیه از چه قراره...
(اینجا هم یه توضیح فوق العاده وجود دارد که بد نیست یه نگاه بهش بندازید)
جمله جذابی که از این بخش باید یادتون بمونه اینه :
"Threading is about workers; asynchrony is about tasks"
وقتی از thread صحبت می کنیم، یعنی دغدغه مون worker ها هستند نه task ها. اگر برگردیم به مثال آشپزخونه، اگه بخوام multiThread برم جلو، میرم worker اضافه می کنم (یعنی آشپز)، ولی وقتی میرم توی مبحث asynchrony دغدغه م task ها است یعنی نمیگم بیا آشپز بیشتر بیار، میگم بیا taskها رو پیش ببریم، یعنی همون آشپزهای موجود را مدیریت کنیم که بی کار نمونن و کارها رو انجام بدهند.
پس کاملا مشخص شد که سطح هدف و دغدغه توی این دو تا مبحث کاملا متفاوته!
حالا سوالی که ممکنه پیش بیاد اینه که کی بریم سراغ استفاده از asynchrony ؟
جمله کلیدی:
"Async Works on I/O Bound, Not CPU-Bound Tasks"
حالا که فهمیدیم بحث مون روی task ها است، میریم بررسی کنیم ببینیم واسه کدوم task ها باید بیایم سراغ asynchrony ؟ یه سری از task ها CPU-Bound هستند یعنی سرعت انجام شون کاملا مبتنی بر سرعت محاسبات سیستم مون است، مثل چی؟ مثل محاسبات ریاضی پیچیده. توی اینجور task ها پردازنده درگیر محاسبات می شود ولی نکته ش اینه که نیازی ندارد تا منتظر ورودی دیگه ای بمونه. این نوع task ها نمی توانند از مزایای asynchronous programming بهره ببرند. (یعنی asynchronous هم بنویسید شون هیچ فرقی به حال شون نمی کنه)
اما task های از نوع I/O-bound آن هایی اند که یه response از یه resource بیرون از خودشون نیاز دارند. این resource خارجی میتونه چی باشه؟ یه database ، یه REST API , ... . وقتی فراخوانی ای به یکی از resource ها انجام میشه، پردازنده اغلب باید منتظر بمونه تا آن ها پاسخ ش رو بدن!
پس هر وقت به یه مرحله ای رسیدیم که توش انتظار برای دریافت پاسخ از یه resource پیش میاد، می تونیم بدون معطلی بریم سراغ استفاده از asynchronous programming !
توی پست بعدی توضیح میدیم که توی asynchronous programming چجوری این قضیه منتظر ایستادن برای دریافت response رو مدیریت می کنه و این که آیا اصلا منتظر وایمیسه یا نه ؟ :)
