برنامه‌نويسي وظيفه‌اي در .Net 4 & 4.5 با TPL و PLINQ

فصل 1: تاريخچه‌ي پردازنده‌ها و برنامه‌نويسي هم‌روند

فصل 2: مفاهيم اوليه

فصل 3: پردازه‌ها و دامنه‌ي برنامه‌ها

فصل 4: برنامه‌نويسي چندنخي سنتي: قسمت اول

فصل 5: برنامه‌نويسي چندنخي سنتي: قسمت دوم

فصل 6: حوضچه‌ي نخ

فصل 7: مباني هماهنگ‌سازي

فصل 8: دستور lock

فصل 9: هماهنگ‌سازي با استفاده از Monitor

فصل 10: سيگنال‌دهي با Monitor

فصل 11: دستگيره‌ي انتظار

فصل 12: دستگيره‌ي انتظار رويداد

فصل 13: موانع حافظه و فرّاري

فصل 14: عمليات اتمي پايه

فصل 15: ساختارهاي دو رگه

فصل 16: قفل‌هاي خواندن و نوشتن

فصل 17: راه‌اندازي کُند به شکل ايمن

فصل 18: انبار محلي نخ يا TLS

فصل 19: تايمرها

فصل 20: فراخواني غير همزمان نماينده‌ها يا ADI

فصل 21: لغو کردن عمليات هرموند و الگوي لغو مشارکتي

فصل 22: توسعه‌هاي موازي يا PFX

فصل 23: توازي وظيفه‌اي

فصل 24: وظايف تو در تو و متوالي

فصل 25: ساير مباحث مرتبط با برنامه‌نويسي وظيفه‌اي

فصل 26: کلاس Parallel

فصل 27: Parallel LINQ

فصل 28: قسمت‌بندي

فصل 29: کلکسيون‌هاي هم‌روند

فصل 30: الگوي برنامه‌نويسي غير همزمان APM: قسمت اول

فصل 31: الگوي برنامه‌نويسي غير همزمان APM: قسمت دوم

فصل 32: الگوي غير همزمان مبتني بر رويداد يا EAP: قسمت اول

فصل 33: الگوي غير همزمان مبتني بر رويداد يا EAP: قسمت دوم

فصل 34: الگوي غير همزمان وظيفه‌اي يا TAP: قسمت اول

فصل 35: الگوي غير همزمان وظيفه‌اي يا TAP: قسمت دوم

فصل 36: نخ‌هاي .NET و فناوري COM

فصل 37: برنامه‌نويسي موازي و واسط کاربر

فصل 38: آزمايش

بررسي کارايي و اشکال‌زدايي برنامه‌هاي هم‌روند

فصل 39: دستورات SIMD و ساير کتابخانه‌هاي برنامه‌نويسي موازي

فصل 40: اختتاميه و جمع‌بندي.

تصحیحات

	سیاوش ابراهیمی ١٣٩٤/١٠/٠٢ ???? ١٠:٠٦ سلام ، در مثال صفحه 206 کتاب قسمت " بهبود دادن تکنیک قفل گذاری با دوبار بررسی " در پایین صفحه ، بعد از قسمت Monitor.enter نیازی به چک کردن متغیر s_value با null نیست این تصحيح توسط omrani مورد پذيرش قرار نگرفته است. علت: ایراد وارد نیست تاريخ رسيدگي: ١٣٩٤/١٠/٠٤ ???? ١٠:١٣
	سيد منصور عمراني ١٣٩٤/١٠/٠٤ ???? ١٠:١٩ ضمن تشکر از توجه شما، ایراد ذکر شده صحیح نیست. علت مساله این است که بین خط قبل از Monitor.Enter() (جایی که s_value برای نخستین بار با null چک می‌شود) و Monitor.Enter() می‌تواند تعویض متن پیش بیاید و درست در همین میان یک نخ دیگر متغیر s_value را پر کند و خارج شود. در این حالت نخ بعدی زمانی Monitor.Enter() را فراخوانی کرده و s_lock را قفل می‌کند که s_value قبلا توسط نخ دیگری پر شده است. لذا نخ فعلی باید پس از Monitor.Enter() نیز چک کند آیا s_value تهی است یا خیر.
	سیاوش ابراهیمی ١٣٩٥/٠٢/٢٣ ???? ٠٠:٥٩ سلام آقای عمرانی . در صفحه 66 کتاب و در مثال 12-4 شما اومدین یک برنامه به شکل کاملا ترتیبی نوشتید و از نخ و فراخوانی به صورت پارامتری خبری نیست .
	سیاوش ابراهیمی ١٣٩٥/٠٢/٢٣ ???? ٠١:٠٧ البته درسته چون نخ اصلی هست و به هرحال اجرا میشه . ولی خوب در اینجا بیشتر انتظار میرفت یک نخ جدید درست بشه و مقادیر به اون ارسال بشه .
	سيد منصور عمراني ١٣٩٥/٠٢/٢٣ ???? ١٦:١٣ بله. اشتباه را درست اعلام کرده‌اید. کُد صحیح بدنه‌ی متد Main بدین صورت است: Thread t = new Thread(new ParameterizedThreadStart(Print)); t.Start("Hello World!"); Console.ReadKey();
	سیاوش ابراهیمی ١٣٩٥/٠٣/٣١ ???? ١٥:٥٩ سلام آقای عمرانی . در صفحه 109 کتاب و در توضیح ساختار پیشفرض Signal شما گفتین که ترتیب اجرای نخ ها تاثیری نداره در حالی که کاملا تاثیر داره . اگر نخ t1 زودتر اجرا بشه Signal میده و به کارش خاتمه میده و با اجرای نخ t2 ، وقتی که به دستور Wait میرسه نخ بلاک میشه و هیچگاه از خواب بیدار نمیشه .
	سيد منصور عمراني ١٣٩٥/٠٤/٠٢ ???? ٢٠:٠١ چنین نیست. دقت کنید ساختار SignalConstruct یک ساختار هماهنگ سازی فرضی است و در .NET چنین کلاسی وجود ندارد. اگر نخ t1 زودتر اجرا شود و Signal() را صدا بزند لزوما سیگنال او هدر نمی رود. هدر رفتن سیگنال به نوع ساختار هماهنگ سازی بستگی دارد. نمونه خوبی از این مساله دستگیره های انتظار (مانند ساختار AutoResetEvent) هستند که در فصل 12 توضیح داده شده است. اگر SignalConstruct را یک AutoResetEvent فرض کنید و نخ t1 متد Set() را برای این ساختار صدا بزند و زودتر از نخ t2 کارش را تمام کند، وقتی اجرای t2 به Wait() می رسد بلاک نمی شود و به کارش ادامه می دهد. اگر نخ t1 نیز دیرتر از t2 کارش را شروع کرده باشد t2 در نقطه Wait() بلاک می شود تا t1 کارش را انجام داده و سیگنال بدهد.
	سيد منصور عمراني ١٣٩٥/٠٤/٠٢ ???? ٢٠:٠٣ نمونه ای از این وضعیت را در مثال 12-1 صفحه 156 می توانید مشاهده کنید. توجه کنید مقصود از هماهنگ شدن t1 و t2 در مثال صفحه 109 این است که t1 و بخش اولیه نخ t2 یعنی متد Task2_1() بتوانند به طور موازی اجرا شوند، اما Task2_2() لزوما باید پس از اجرای t1 اجرا شود.
	سیاوش ابراهیمی ١٣٩٥/٠٤/١٥ ???? ١٩:٤٦ سلام آقای عمرانی ، در صفحه 177 کتابتون و در مثال 2-14 به گمانم باید مثدار متغیر value رو برگشت بدین و نه calc . چون که در داخل دستور lock اومدین مقدار جدید رو در Value قرار دادین و همچنین دستور CompareExchange هم مقدار رو در همین متغیر قرار میده
	سيد منصور عمراني ١٣٩٥/٠٤/١٦ ???? ٢٢:٢٥ حق با شما است. اما واقعیت این است که متد MultiplyBy() نیز اصلا نیازی به مقدار برگشتی ندارد. زیرا حاصلضرب در نهایت داخل خود Value قرار خواهد گرفت و Value نیز یک متغیر public است.
	سيد منصور عمراني ١٣٩٥/٠٤/١٦ ???? ٢٢:٤٠ توجه کنید مثال 2-14 نسخه تکمیل شده مثال 1-14 است که از فصل 22 کتاب C# 4.0 in a Nutshell صفحه 924 اخذ شده است. در کتاب مزبور پیش از انجام محاسبه از Thread.MemoryBarrier() و پس از مقایسه از spinwait.SpinOnce() استفاده شده تا در سناریوهای همروندی بسیار بالا از به دام افتادن پردازنده در اختیار نخی که عمل حاصلضرب را انجام میدهد جلوگیری شود. توصیه میکنم ساختار SpinWait را در کتاب مزبور (صفحه 922 تا 925) نیز حتما مطالعه نمایید.
	امیر س ١٣٩٥/٠٧/٢٤ ???? ٢٢:٠٤ سلام وقت بخیر... اگه این نمونه پی دی افی که گذاشتید چندصفحه محتویات کتاب هم میبود بهتر میشد! این که همش فهرسته!! اگه چندصفحه از محتوای آنرا هم بذارید بد نیست باور کنید با چندصفحه محتوا از یک کتابی به این مفیدی چیزی از زحمات نویسنده کاسته نمیشه!

مخاطبین

نیازمندی ها