اصول و الگوهای چند رشته ای

عکس توسط ناتاشا پلیکووا / Unsplash

همانطور که در حال مطالعه سیستم عامل ها بودم ، در مورد برنامه های چند رشته ای و نحوه کار آنها آموختم. من با خوشحالی از دیدن اینکه آنها الگوهای طراحی خود را دریافت کرده اند ، شگفت زده شدم.

به عنوان مرد با حدود 9 مقاله در مورد الگوهای مختلف طراحی ، من فقط مجبور شدم چیزی در مورد آن بنویسم.

خوب اینجا چیزی پیش نمی رود.

امروز تمام اصول محبوب و الگوهای طراحی را خلاصه می کنم.

الگوهای چند رشته ای چیست؟

برنامه نویسی چند رشته ای بسیار حساس است.

بسیاری از موارد ممکن است اشتباه پیش بروند و اشکال زدایی آنها بسیار سخت است.

در صورت عدم دقت ، مواردی از قبیل بن بست و متوقف کردن داده های شما بسیار متداول است.

به همین دلیل ، یک دسته از برنامه نویسان هوشمند ، با گذشت سالها الگویی برای طراحی بهتر کد چند رشته ای ایجاد کرده اند.

آنها تقریباً همان الگوهای طراحی هستند اما برای برنامه های چند رشته ای.

اصول مفید برای برنامه نویسی چند رشته ای

اشیاء تغییر ناپذیر

اشیاء تغییر ناپذیر قابل تغییر نیستند. وضعیت آنها همان است. تنها راه "تغییر" آنها این است که ابتدا یک کپی از شی را ایجاد کنید و سپس آن را در حالت جدید منتقل کنید.

اشیاء تغییر ناپذیر مفید هستند زیرا:

• آنها از موضوع ایمن هستند ، به این معنی که داده های مشترک را در یک محیط چند رشته ای به درستی دستکاری می کنند.
• درک آنها ساده است.
• آنها سطح بالایی از امنیت را ارائه می دهند.
• توابع عوارض جانبی ندارند.

این الگوی آنقدر محبوب است که یک شاخه دیگر از برنامه نویسی به نام برنامه نویسی کاربردی به طور پیش فرض از اشیاء تغییر ناپذیر استفاده می کند.

اما اشکالاتی وجود دارد ، می تواند:

• برای ایجاد اشیاء جداگانه برای هر تغییر بسیار پر هزینه است.
• غیر عملی برای تغییر برخی از اشیاء به دلیل تغییر آنها.
• درد برای اجرای

به طور خلاصه ، تغییر ناپذیری برای اشیاء که مانند مقادیر رفتار می کنند خوب است یا فقط چند خاصیت دارند. قبل از اینکه هر چیزی تغییر ناپذیر باشد ، باید پس از تغییرپذیری آن ، تلاش مورد نیاز و قابلیت استفاده خود کلاس را در نظر بگیرید.

می توانید اطلاعات بیشتر در مورد اشیاء تغییر ناپذیر را در اینجا بخوانید:

بنیاد ویکی مدیا ، شرکت در پروژه های ویکی مدیا

اصل جدایی پرس و جو فرمان

منبع: https://www.dotnetcurry.com/pattes-practices/1461/command-query-separation-cqs

اصل جدایی پرس و جو (CQS) بیان می کند که تمام روشهای یک شیء باید باشد:

• پرس و جو در جایی که داده ها را برمی گردانید اما حالت را تغییر نمی دهد.
• یک فرمان که در آن حالت را اصلاح می کنید اما داده ها را برمی گردانید.

مزایای این رویکرد عبارتند از:

• تفکیک نگرانی ها - کد شما ساختار بیشتری خواهد بود ، از این رو به شما انگیزه می دهد تا کد جامد بیشتری را دنبال کنید و تست های واحد بیشتری بنویسید.
• بهینه سازی عملکرد - از آنجا که خواندن و نوشتن ما از هم جدا شده است ، می توانیم خیلی راحت عملکرد را بهینه کنیم. این از طرف خوانده شده با ارزش تر است زیرا بیشتر برنامه ها بیشتر محور هستند.
• CQRS - CQRS گسترش CQS اما در سطح معماری تر است. از آنجا که کد ما ساختار یافته تر است ، می توانیم از "شیوه های" مختلفی برای خواندن و نوشتن استفاده کنیم. به عنوان مثال ، به جای استفاده از یک پایگاه داده SQL برای خوانده شده ، می توانیم از NOSQL استفاده کنیم.
• اجرای - این اصل به راحتی قابل اجرا است.

مثل همیشه هیچ چیز کامل نیست. من پیشنهاد نمی کنم که از این الگوی به صورت مذهبی استفاده کنید ، گاهی اوقات بازگشت داده ها در یک دستور سودمندتر است. به عنوان مثال ، روش Array POP در اکثر زبانهای برنامه نویسی این الگوی را می شکند اما با این وجود ، این یک روش بسیار مفید است.

برای مطالعه بیشتر در مورد CQS ، پیشنهاد می کنم این مقاله را توسط مارتین فاولر بخوانید.

نکات دیگر در مورد برنامه نویسی چند رشته ای

• از ویژگی های زبان و کتابخانه ای که از آنها استفاده می کنید مانند لیست های همزمان و ساختارهای موضوعی استفاده کنید زیرا آنها به خوبی طراحی شده اند و عملکرد خوبی دارند.
• اگر در MultitHreading تازه کار هستید ، کوچک را شروع کنید و کارها را ساده نگه دارید - وقت بگذارید تا واقعاً بفهمید که چگونه موضوعات شما با یکدیگر تعامل دارند - چه موضوعاتی در همان زمان انجام می دهند و چه موضوعاتی خواهند بودمنتظر همدیگر

الگوهای طراحی چند رشته ای

این بخش از مقاله به معنای مرجع بیشتر است ، بنابراین احساس راحتی کنید.

ps. تمام نمونه های کد به صورت شبه کد خواهد بود زیرا بیشتر این الگوهای جهانی هستند.

شیء فعال (الگوی بازیگر)

منبع

شیء فعال یک الگوی طراحی است که با جداشدگی اجرای روش از دعوت روش ، همزمانی را معرفی می کند.

اما ممکن است بگویید ، "آیا اجرای روش نیست و همان کار را دعوت می کند؟"

از نظر فنی بله ، اما نه.

زمان فراخوانی زمان لازم برای فراخوانی یا تماس با روش است. زمان اجرای زمان لازم برای اجرای بدنه روش است.

بنابراین آنچه این الگوی انجام می دهد این است که این روش را از بدن اجرایی خود جدا می کند.

خوب Smartass ، چگونه ما واقعاً این کار را انجام می دهیم؟

خوب ، این الگوی چهار عنصر اصلی دارد:

• پروکسی (یا رابط مشتری) - رابط کاربری به مشتریانی که روشهای عمومی شیء فعال ما را تعریف می کند.
• صف اعزام - لیستی از درخواست های در انتظار مشتری.
• برنامه زمانبندی - تصمیم می گیرد که کدام درخواست برای اجرای بعدی.
• دسته نتیجه (یا پاسخ به تماس) - این اجازه می دهد تا پس از اجرای درخواست ، نتیجه حاصل از پروکسی حاصل شود.

شبه کد چیزی شبیه به این خواهد بود:

در اینجا یک راهنمای گام به گام در مورد آنچه اتفاق می افتد آورده شده است:

1. وقتی نمونه ای از ActiveObject را ایجاد می کنیم ، یک موضوع جدید ایجاد می کنیم که روش RUN_TASKS را اجرا می کند.
2. روش run_tasks منتظر هر روش دیگری در dispatch_queue ما است و آنها را اجرا می کند.
3. روشهای دیگر ما مانند increment_count و decrement_count منطق خود را به عنوان توابع به dispatch_queue سوق می دهد.

شیء

منبع: https://www.researchgate. net/figure/the-monitor-object-patte-class-ciagram-revised-from-sch00-bhs07a_fig8_319185849

Monitor Object یک الگوی طراحی است که برای ایجاد اشیاء ایمن نخ و جلوگیری از درگیری بین موضوعات در برنامه های همزمان استفاده می شود.

ممکن است بپرسید "" امنیت موضوع چیست؟ "

به سادگی ، امنیت موضوع به این معنی است که می توان یک روش یا نمونه کلاس را همزمان با موضوعات مختلف و بدون هیچ مشکلی استفاده کرد.

به عنوان مثال ، بیایید این مثال را در نظر بگیریم:

اگر ما دو موضوع را در حال افزایش عملکرد داشته باشیم ، ممکن است Thread-1 داده ها را اجرا کند و نتیجه گیری کنیم که پیشخوان 0 است ، موضوع 2 نیز به طور همزمان شروع به کار کرد و همچنین نتیجه گرفت که پیشخوان 0 است. در پایان ، پیشخوان یک بار افزایش یافته استاگرچه همزمان توسط دو موضوع اجرا می شد.

این نوع مشکلاتی که داده ها در محیط های چند رشته ای به طور نادرست مورد استفاده قرار می گیرند ، شرایط مسابقه نامیده می شوند.

قفل کردن داده ها یکی از مکانیسم های رفع آن است و اینگونه است که مانیتور اشیاء کار می کنند تا داده ها بین چندین موضوع هماهنگ شوند.

اجرای آن بسیار ساده است ، بنابراین در اینجا شبه کد وجود دارد.

این به همان سادگی است که می تواند بدست آورد.

ما به سادگی از یک قفل استفاده می کنیم تا با خیال راحت داده های خود را جهش دهیم.

بیشتر زبانهای برنامه نویسی مقداری قند نحوی دارند تا اجرای این الگوی را آسان تر کند. به عنوان مثال ، جاوا روشهای "هماهنگ" را دارد تا به راحتی از دسترسی داده ها توسط چندین موضوع به طور همزمان جلوگیری شود.

الگوی انسداد

منبع: https://java-design-pattes.com/pattes/balking/

از الگوی ممانعت برای جلوگیری از اجرای یک شیء در صورت وجود در حالت ناقص یا نامناسب استفاده می شود.

شما معمولاً از این الگوی استفاده می کنید:

• شما روشی را پیدا کردید که فقط با یک حالت خاص روی یک شیء کار کند.
• اشیاء به طور کلی برای مدت نامحدودی در وضعیت نامناسب قرار دارند ، از این رو به همین دلیل ما روشهای خود را "محاصره" می کنیم.

بیایید نمونه ضد ما را گسترش دهیم ، اگر پیشخوان ما 0 باشد ، ما نمی توانیم آن را کاهش دهیم.

برای اجرای این قابلیت با استفاده از الگوی انسداد ، ما چنین کاری را انجام می دهیم:

به طور خلاصه ، این بیشتر از الگوی شیء مانیتور با شرط بندی مبتنی بر حالت است.

برخی از دانشمندان رایانه ای وجود دارند که الگوی ممانعت را به عنوان یک الگوی ضد الگوی می دانند اما به طور کلی ، این وظیفه شماست که تصمیم بگیرید که متناسب با نیازهای شما باشد یا نه.

به غیر از این ، اگر بدانید که یک شیء برای مدت زمان محدود در وضعیت نامناسب قرار خواهد گرفت ، چند گزینه دیگر وجود دارد. اگر از الگوی تعلیق محافظت شده استفاده کنید بهتر خواهد بود.

در اینجا شما میتوانید اطلاعات بیشتری راجع به آن بخوانید:

بنیاد ویکی مدیا ، شرکت در پروژه های ویکی مدیا

الگوی تولید کننده

منبع: http://tutorials. jenkov.com/java-concurrency/producer-consumer.html

الگوی تولید کننده-مصرف کننده یک الگوی طراحی همزمانی کلاسیک است که دعوت روش را از اجرای روش جدا می کند.

این کار را با تعیین فرآیندها به عنوان هر دو انجام می دهد:

• تولید کننده - تولید کننده به جای پردازش سریع آنها ، کار را برای پردازش بعدی وارد می کند.
• مصرف کننده - مصرف کننده سپس یک مورد کار را از صف می گرفت و هر زمان که رایگان باشد آن را پردازش می کند.

این موارد استفاده متداول برای این الگوی است:

• تأخیر نخ پیش زمینه را کاهش دهید - معمولاً ، یک موضوع پیش زمینه با دنیای خارج ارتباط برقرار می کنید. به عنوان مثال ، در یک برنامه وب ، این موضوع درخواست های HTTP را کنترل می کند. مسئله در صورتی پیش می آید که درخواست ها گران شوند و زمان زیادی را برای محاسبه خود می گیرند ، این موضوع در حال مسدود کردن سایر درخواست های دریافتی است. بنابراین راه حل این است که این موضوع اجرای درخواست HTTP را به برخی از موضوعات پس زمینه دیگر ارائه دهد تا بتواند درخواست های HTTP دیگر را بپذیرد.
• تعادل بار بین موضوعات مختلف کار کنید - اگر اقدامات گران قیمت دارید ، می توانید تعادل آنها را بارگذاری کنید تا به طور موثر در چندین موضوع اجرا شوند.
• مدیریت فشار خون - فشار خون هنگامی اتفاق می افتد که تولید کننده شما بیشتر از آنچه مصرف کنندگان می توانند کار کنند ، کار بیشتری انجام می دهد. اگر صف محدود داشته باشید ، صف اساساً پر می شود و این باعث می شود تولید کنندگان شما از فشار بیشتر کار به صف جلوگیری کنند. به این حالت فشار خون گفته می شود. این سیستم در برابر تولید کنندگان فشار می آورد.

حال بیایید نحوه اجرای این الگوی را بررسی کنیم.

یک روش غیر متداول برای اجرای الگوی تولید کننده مصرف کننده استفاده از semaphores است.

منبع: https://www.geeksforgeeks.org/semaphores-in-process-synchronization/

یک semaphore یک ساختار داده است که به موضوعات کمک می کند تا بدون دخالت در یکدیگر همکاری کنند.

استاندارد POSIX رابط کاربری برای semaphores را مشخص می کند. این بخشی از pthreads نیست ، اما بیشتر یونیکس هایی که pthreads را پیاده سازی می کنند ، سمیفور ها را نیز ارائه می دهند.

این رابط تعریف شده برای semaphores posix است:

بیایید به سرعت روش ها را طی کنیم:

• make_semaphore - این عملکرد ایجاد semaphore ما است ، مقدار اولیه semaphore را به عنوان یک پارامتر می گیرد. فضا را اختصاص می دهد ، آن را آغاز می کند و یک نشانگر را به semaphore باز می گرداند.
• semaphore_wait - این عملکرد تعداد semaphore را کاهش می دهد. اگر تعداد semaphore بعد از کاهش منفی باشد ، موضوع فراخوانی بلوک می شود.
• semaphore_signal - این عملکرد تعداد semaphore را افزایش می دهد. اگر شمارش غیر منفی باشد (یعنی بیشتر از یا برابر با 0) و یک نخ در سمیفور مسدود می شود ، برنامه انتظار برای اجرای آن قرار دارد.

با استفاده از semaphores ، ما می توانیم یک تولید کننده ساده را اجرا کنیم:

الگوی سد

بهترین تعریفی که در این باره دریافت کردم مربوط به ویکی پدیا است:

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

این بسیار توضیحی است ، سد تمام موضوعات را متوقف می کند تا اینکه همه موضوعات دیگر به این سد برسند.

بیایید به یک مثال اساسی نگاه کنیم. سد اساسی دارای دو متغیر اصلی است:

• یکی از آنها وضعیت عبور/توقف مانع را ثبت می کند.
• مورد دیگر تعداد کل موضوعاتی را که وارد سد شده اند ، نگه می دارد.

حالت اولیه مانع "توقف" است. هنگامی که یک نخ وارد می شود ، و اگر آخرین موضوع باشد ، وضعیت سد به "عبور" تغییر می کند تا تمام موضوعات دیگر بتوانند از سد خارج شوند. از طرف دیگر ، هنگامی که نخ ورودی آخرین مورد نیست ، در سد به دام می افتد و اگر حالت سد از "توقف" به "عبور" تغییر کرده باشد ، آزمایش را ادامه می دهد و فقط وقتی حالت سد تغییر می یابد"عبور".

در اینجا یک مثال C ++ است که من از ویکی پدیا کپی کردم:

قفل دوتایی

منبع: https://java-design-pattes.com/pattes/double-checked-locking/

قفل دو چک یک الگوی طراحی است که برای کاهش سربار قفل با آزمایش اول معیار قفل ("اشاره قفل") قبل از دستیابی به قفل استفاده می شود.

شما می توانید از این به عنوان اولیه سازی تنبل فکر کنید ، فقط در صورت نیاز یک متغیر را اولیه می کنید.

این نمونه ای از الگوی است:

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

الگوی رهبران/پیروان

ps. برای الگوی زیر ، من به معنای واقعی کلمه یک پاسخ stackoverflow را از اینجا کپی کرده ام.

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

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

• اول ، موضوع موضوع بعدی (پیرو) را در صف اطلاع می دهد ، که به رهبر جدید تبدیل می شود و شروع به گوش دادن به درخواست های جدید می کند
• سپس ، موضوع با پردازش درخواستی که قبلاً دریافت شده است ، پیش می رود.

نمودار زیر نشان می دهد که چگونه در سطح بالایی کار می کند.

اگر می خواهید اطلاعات بیشتری کسب کنید ، ما فقط سطح را با این الگوی خراشیده ایم. این یک مقاله عالی در مورد الگوی رهبر/پیروان است.

نتیجه

خوب این طولانی بود ، من مطمئن هستم که بسیاری دیگر را از دست داده ام.

اگر من اشتباه کردم یا نوشتم ، احساس راحتی کنید که در توییتر من را نقد کنید.

با تشکر از خواندن

برای این کار بیشتر ثبت نام کنید.

ایجاد API های استراحت با استفاده از Go ، Gorm و PostgreSQL

یکی از متداول ترین کاربردها برای GO ، ساخت خدمات پس زمینه است. این بیشتر شامل ایجاد API های استراحت است.(اگر با API های استراحت آشنا نیستید ، در اینجا یک فیلم عالی از IBM توضیح داده شده است.) API REST چیست؟ درباره API ها بیشتر بدانید: http://ibm.biz/guide-to-apislea بیشتر

مقدمه ای برای معیارهای دورا

چرا باید به معیارها اهمیت دهیم؟زیرا به ما می گوید که آیا ما به جلو حرکت می کنیم یا به عقب. در دنیای DevOps از معیارهای دورا استفاده می کنیم. این همان چیزی است که امروز در مورد آن صحبت خواهیم کرد. امروز خواهید آموخت: * معیارهای دورا چیست؟* چه نیازی به آنها داریم؟* مزایای آن

Kubeetes برای آدمک ها

دنیای نرم افزار از افزایش محبوبیت کانتینر تغییر کرده است. از فناوری هایی مانند Docker برای مدیریت و چرخش سریع ظروف استفاده می شود. این در شرکت های بزرگی مانند Google مورد استفاده قرار گرفته است اما آنها یک مسئله بزرگ داشتند. ظروف زیادی وجود داشت. شرکت