سلام؛ سعی کردم توی این نوشته، بخش های مهم ارائه Concurrency is not parallelism که توسط Rob Pike رو یه جورایی ترجمه کنم. و خوشحال میشم اگر مشکلی توی متن یا ترجمه بود کامنت بزارید تا تصحیح اش کنم.
این ارائه نسبتا طولانیه پس قراره چند تا پارت داشته باشیم و میتونید لینک پارت های بعدی رو در انتهای نوشته پیدا کنید.
و اسلاید های ارائه رو هم میتونید از اینجا ببینید.
چیزی که تقریبا همه ی کسانی که حداقل یه بار به go سَرَک کشیدن راجبش میدونن، اینه که go خیلی خوب از concurrency پشتیبانی میکنه.
ولی خب اکثر مردم concurrency رو با parallelism اشتباه میگیرن، یا حتی اونا رو یکی میدونن! درسته به هم مروبط هستند ولی دوتا مفهوم کاملا متمایز از همدیگه هستند! چیزی که مردم رو گیج میکرد این بود که برنامشون رو با چند تا پردازنده اجرا میکردند ولی کندتر عمل میکرد! و اونا فکر میکردند خرابه و کار نمیکنه، ولی در واقع چیزی که خراب بود دیدگاه اونا راجب این مسئله بود.
ممکنه اول این نوشته متوجه تفاوتشون نشید، ولی هرچقدر بیشتر بخونید و جلوبرید به درک دقیق و عمیق تری از تفاوت این دو میرسید.
میشه گفت concurrency ترکیب فرایند هایی (میشه گفت function ها) هستند که به طور مستقل از هم به طور همزمان اجرا میشوند.
Concurrency is about dealing with lots of things at once.
در واقع concurrency به معنای برخورد همزمان با خیلی چیزاست.
خب parallelism اجرای همزمان چیزهایی هستند که میتونن به هم مربوط باشن یا نباشن!
Parallelism is about doing lots of things at once.
یعنی Parallelism به معنای انجام همزمان چندتا کاره...
این دوتا خیلی شبیه به هم هستند، ولی واقعا دوتا مفهوم جدا از هستند. یعنی concurrency در مورد ساختار است ولی parallelism در مورد اجرا.
بنابراین concurrency راهی برای ساخت یک چیز است، تا شاید بتوان از parallelism برای انجام بهتر کار استفاده کرد، اما parallelism، هدف concurrency نیست. هدف concurrency ساختار خوب است.
بیشتر بخوام بگم، concurrency راهی برای ساختار یک راه حل برای حل مسئله ارائه می دهد که ممکن است (اما نه لزوما) قابل موازی سازی (parallelism) باشد.
کامپیوتر هامون با mouse , keyboard و... در ارتباط هستند، که توسط سیستم عامل به شکل مستقل داخل kernel مدیریت میشن. یعنی به صورت concurrent و اونها لزوما parallel نیستن.
اگر فقط یک processor داشته باشیم، فقط یکی از این ها در لحظه در حال اجرا هستند. بنابرین یک مدل concurrent برای اینها وجود داره. پس ذاتا parallel نیستند. یعنی لازم نیست parallel باشند!
بنابرین اگر بخوایم برای اجرای parallel مثال بزنیم، میشه ضرب داخلی بردار رو مثال زد، که میتونی تقسیمش کنیم به چندتا عملیات کوچیکتر و به صورت parallel اجراشون کنیم.
بنابرین concurrency راه و ساختاری رو ارائه میده، که بتونیم روی قطعات مستقل از هم کار کنیم یا بهتره اینجوری بگم که concurrency راهی برای ساختار یک برنامه با شکستن آن به قطعاتی است که می توانند به طور مستقل اجرا شوند. و ما نیاز داریم که این قطعات رو با همدیگه هماهنگ کنیم و برای انجام این کار نیاز به نوعی ارتباط بین اونها داریم.
و Tony Hoare در سال 1978، مقاله ای به اسم communicating sequential processes نوشت که واقعا یکی از بزرگترین مقالات در علوم کامپیوتر است.که بسیاری از آدمها ابزار هایی برای استفاده از ایده های او در زبان های concurrent مثل Erlang و... ساخته اند. و خب go هم برخی از این ایده هارو توی خودش داره.
(و Rob Pike توصیه کرده که حتما این مقاله رو بخونیم)
توی پارت بعدی قراره از gopher هامون یخورده کار بکشیم پس حتما برای درک بهتر موضوع این پارت رو هم بخونید ؛)
