<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های shahrzad jahanbaz</title>
        <link>https://virgool.io/feed/@iamtheone</link>
        <description>برنامه نویس و عاشق توسعه دادن هر چیزی که بشه توسعه ش داد چه کد باشه چه زندگی :)</description>
        <language>fa</language>
        <pubDate>2026-06-16 17:38:24</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/71613/avatar/3xKb3z.png?height=120&amp;width=120</url>
            <title>shahrzad jahanbaz</title>
            <link>https://virgool.io/@iamtheone</link>
        </image>

                    <item>
                <title>درک Asynchronous Programming در #C (دومین قسمت : درک تفاوت Multithreading و asynchronous)</title>
                <link>https://virgool.io/@iamtheone/%D8%AF%D8%B1%DA%A9-asynchronous-programming-%D8%AF%D8%B1-c-%D8%AF%D9%88%D9%85%DB%8C%D9%86-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D8%B1%DA%A9-%D8%AA%D9%81%D8%A7%D9%88%D8%AA-multithreading-%D9%88-asynchronous-d6kpamuwkcv1</link>
                <description>توی پست اول متوجه شدیم که وقتی می گیم یه کد، Asynchronous کار می کند ، منظورمون چیه. حالا میریم سراغ این که آیا Asynchronous همون Multithreading ه یا نه؟خب جواب این سوال، خیر است :) یعنی کدی که Asynchronous نوشته شده است، هرگز مثل کدی که از multithreading استفاده می کند، نیست.توی مبحث multithreading، همانطور که از اسمش پیداست کارها روی thread های کاملا مجزا انجام می شوند به صورتی که هیچ گونه ارتباطی بین این thread ها وجود ندارد. اما توی مبحث Asynchronous Programming یه نقاطی هست که thread ها می توانند از آنجا کار باقی مونده رو به دست بگیرند و ادامه ش بدهند و یا این که یه کار رو رها کنند و برن سراغ یه کار دیگه. (توی مقالات بعدی خیلی مفصل این بخش رو باز می کنیم!) اینجا قراره بفهمیم مساله اصلی، انتظار است :)اگر مقاله قبلی رو خونده باشید، الان با این مثال من کاملا متوجه میشید که قضیه از چه قراره...(اینجا هم یه توضیح فوق العاده وجود دارد که بد نیست یه نگاه بهش بندازید)جمله جذابی که از این بخش باید یادتون بمونه اینه :&quot;Threading is about workers; asynchrony is about tasks&quot;وقتی از thread  صحبت می کنیم، یعنی دغدغه مون worker  ها هستند نه task ها. اگر برگردیم به مثال آشپزخونه، اگه بخوام multiThread برم جلو، میرم worker اضافه می کنم (یعنی آشپز)، ولی وقتی میرم توی مبحث asynchrony دغدغه م task ها است یعنی نمیگم بیا آشپز بیشتر بیار، میگم بیا taskها رو پیش ببریم، یعنی همون آشپزهای موجود را مدیریت کنیم که بی کار نمونن و کارها رو انجام بدهند. پس کاملا مشخص شد که سطح هدف و دغدغه توی این دو تا مبحث کاملا متفاوته! حالا سوالی که ممکنه پیش بیاد اینه که کی بریم سراغ استفاده از asynchrony ؟جمله کلیدی: &quot;Async Works on I/O Bound, Not CPU-Bound Tasks&quot;حالا که فهمیدیم بحث مون روی 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 رو مدیریت می کنه و این که آیا اصلا منتظر وایمیسه یا نه ؟ :)</description>
                <category>shahrzad jahanbaz</category>
                <author>shahrzad jahanbaz</author>
                <pubDate>Mon, 13 Apr 2020 10:41:58 +0430</pubDate>
            </item>
                    <item>
                <title>درک Asynchronous Programming در #C (اولین قسمت : درک تفاوت  synchronous و  asynchronous)</title>
                <link>https://virgool.io/@iamtheone/%D8%AF%D8%B1%DA%A9-asynchronous-programming-%D8%AF%D8%B1-c-%D9%88-aspnet-%D8%A7%D9%88%D9%84%DB%8C%D9%86-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D8%B1%DA%A9-%D8%AA%D9%81%D8%A7%D9%88%D8%AA-synchronous-%D9%88-asynchronous-nzuy0ks4gszd</link>
                <description>اولین نکته ای که خیلی مهم و به جاست که همین اول کار راجع بهش صحبت کنیم اینه که Asynchronous Programming چی نیست و چی کار نمی کنه ! اولین باور اشتباهی که معمولا خیلی دیده میشه اینه که استفاده از Asynchronous Programming باید performance کدمون رو بالا ببره! که اصلا لزوما اینطور نیست (شاید هم بشه ها ولی الزاما هدف ما این نیست) یعنی دغدغه ی ما توی این مفهوم، اصلا سرعت نیست . چیزی که Asynchronous Programming به کد ما می بخشه اینه که در نهایت ما نسبت به حالت synchronous، تعداد request  بیشتری را می تونیم در یک زمان مشابه با منابع (resource ) مشابه مدیریت کنیم. -مثال می زنم تا یه کمی قضیه واضح تر بشه:فرض کنید یه رستوران داریم که طبق سیستم روتین همه رستوران ها، وقتی سفارش ها از مشتریان گرفته میشه ، میره آشپزخونه تا توسط آشپز ها آماده بشوند. خب اینجا بیاید اینطوری فرض کنیم که دو نوع آشپزخونه داریم : synchronous و  asynchronous .توی آشپزخونه اول (که قراره synchronous طور باشه ) این شکلی ه که اگر یه آشپزی یه سفارش رو می پذیره، ولش نمی کنه تا وقتی که کامل بشه :)  یعنی چی؟ یعنی اگر مثلا توی مراحل تهیه غذا به مرحله ای رسیدیم که اون غذا به فر احتیاج داره، آشپز غذا رو میذاره توی فر و خیلی صبورانه جلوی در فر میشینه و زل میزنه به فر تا غذا آماده شود و توی این زمانی که منتظره، هیچ کار دیگه ای انجام نمیده (تاکید می کنم هیچ کاری :)  ) . بنابراین توی این آشپزخونه اگر x  تا آشپز داشته باشیم، به صورت همزمان فقط x تا سفارش آماده می شود.مثلا این آشپزخونه مونه :) توی آشپزخونه دوم  که asynchronous  است اما اصلا اوضاع این شکلی نیست، اصلا فرض کنید این یکی آَشپزخونه شعارش اینه : &quot;no idle time&quot;  (تایم بیکاری نداریم!) مثلا اگر یه آشپزی توی این آشپزخونه یه سفارشی رو قبول کنه و شروع کنه به آماده کردن ش، و مثلا وسط ش نیاز باشه که اون غذا بره داخل فر، اون آشپز حق نداره بیکار باشه، باید توی این تایم بره یه کار دیگه ای انجام بده. با یه مقایسه ساده کاملا میشه فهمید که تعداد غذاهایی که این آشپزخونه می تونه آماده کنه با همون تعداد آشپز، خیلی بیشتر از اون یکی آشپزخونه است،چرا؟ چون هیچ آشپزی قرار نیست منتظر بمونه. و نکته جالب ش اینجاست که اصلا حرفی از این نزدیم که آشپزها قراره سریع تر کار کنن چون اصلا اینطوری نیست، آشپزها توی هر دو تا آشپزخونه به همان سرعت و روش معمول خودشون کارها رو میبرن جلو. (یعنی میخوام تاکید کنم علت این که آشپزخونه asynchronous  سفارش بیشتری آماده می کنه، بیشتر بودن سرعت آشپزهاش نیست! )دقیقا می رسیم به همون جمله ای که اولش گفتیم که با یه مقدار مشخص و یکسانی از منابع (resource) که اینجا آشپزها هستند که توی دو تا رستوران برابرند و در یک زمان یکسان، با استفاده از پیاده سازی Asynchronous  تونستیم میزان request  بیشتری رو مدیریت کنیم.(request اینجا تعداد سفارش ها است.)پس تا اینجا نکته ای که باید توی ذهن مون نگه داریم اینه که هدف اصلی asynchronous programming توی asp.net افزایش throughput یا همون بهره وری است . ( که توی مثال رستوران میشه تعداد سفارش هایی که هر رستوران می تونه آماده کنه! )توی قسمت های بعدی راجع به تفاوت این مفهوم با MultiThreading صحبت می کنم. </description>
                <category>shahrzad jahanbaz</category>
                <author>shahrzad jahanbaz</author>
                <pubDate>Sun, 12 Apr 2020 15:11:42 +0430</pubDate>
            </item>
            </channel>
</rss>