Parallel بایگانی - تاد

Bo-taoshi

شرایط رقابتی و قفل بین‌پروسه‌ای در PHP

توسط | مقالات فنی | نظری داده نشده.

[این مقاله در سطح «پیشرفته» و نیازمند آشنایی خواننده با زبان PHP و نرم‌افزار Redis و مفاهیم «شرایط رقابتی» و «Shared Object» است.]

کنترل دسترسی چند پروسه به منابع مشترک یا shared object ها از مسائلی است که روزانه در زندگی واقعی برنامه‌نویسان رخ می‌دهد. مدیریت این گونه از مسائل اهمیت بسیار زیادی در پیاده‌سازی نرم‌افزارها و سرویس‌های توزیع‌شده دارد. پیامد مدیریت نادرست این مسأله منجر به ایجاد شرایط رقابتی و بروز باگ‌های غیرقابل پیگیری در برنامه می‌شود. آشفته‌بازار شرایط رقابتی چیزی شبیه به رقابت سنتی بو-تااوشی در ژاپن است در آن هر فرد از تیم رقیب، به هر طریق و وسیله‌ای، موظف است دکل میانه‌ی میدان را به زیر بکشد.

برنامه‌نویسان PHP شاید از معدود برنامه‌نویسانی باشند که کمتر با این گونه مشکلات درگیر هستند و به آن فکر می‌کنند. طراحی زبان PHP به گونه‌ای است که به هر فرد به صورت جداگانه سرویس‌دهی کند و اشتراک داده‌ها بین متقاضیان سرویس از طریق اطلاعات ذخیره‌شده در پایگاه داده‌ی MySQL انجام شود. پایگاه‌های داده‌ای مانند MySQL کنترل دسترسی پروسه‌ها را به صورت درونی انجام می‌دهند و برنامه‌نویس نیازی به نگرانی در مورد آن ندارد. اما بدون ذکر مصداق و بنا بر تجربه‌ی شخصی نگارنده، حتی در PHP هم ممکن است شرایطی رخ دهد که چند پروسه‌ی PHP نیاز به دسترسی به داده‌های مشترکی داشته باشند که ذاتاً هیچ کنترلی برای دسترسی به آنها وجود ندارد.

متأسفانه زبان PHP ذاتاً دارای سازوکاری برای استفاده از راه حل‌های معمول و منطقی امروزی، مانند semaphore و mutex، را ندارد. اما این به آن معنی نیست که چنین کاری در PHP امکان‌پذیر نباشد. در ادامه‌ی این مقاله سعی شده است تا چند نمونه از راهکارهای موجود در PHP برای پرهیز از شرایط رقابتی و مزایا و معایب آنها ارائه شود.

Read More

Chinese New Year Crowds from CNN

چطور یک Thread Pool بسازیم!

توسط | مقالات فنی | نظری داده نشده.

[این مقاله در سطح «متوسط» و نیازمند آشنایی خواننده با مفهوم «پردازش موازی» و زبان برنامه‌سازی «++C» است.]

در پیاده‌سازی سرویس‌دهنده‌ها موارد بسیاری وجود دارد که در آن نیازمند پردازش درخواست‌های کوچک اما متعدد هستیم. برای درک بهتر مسأله یک شعبه‌ی بانک یا یک باجه‌ی فروش بلیت را در نظر بگیرید. در مثال شعبه‌ی بانک، تعداد مراجعان در طول یک روز غالباً بسیار زیاد است. پاسخ به درخواست هر مراجع ممکن است (به طور مثال) از ۵ تا ۵۰ دقیقه طول بکشد. آنچه برای شما به عنوان یک مراجع مهم است، سرعت شعبه‌ی بانک در پاسخ به درخواست شماست و احتمالاً دوست ندارید مدت‌ها در صف طولانی مراجعان بانک حضور داشته باشید. اگر از منظر رئیس شعبه به آن نگاه کنید، با دو مسأله روبرو هستید. از سویی، مراجعان از کندی سرعت شما در پاسخگویی گلایه خواهند کرد. از سوی دیگر، شما با توجه به منابع انسانی و مالی که در دسترس دارید نمی‌توانید بیش از توانتان به باجه‌های پاسخگویی اضافه کنید.

سرویس‌دهنده‌ها با مسأله مشابهی روبرو هستند، با این تفاوت که مراجعان همان درخواست‌های دریافت‌شده و منابع در دسترس همان پردازنده‌ها و حافظه هستند. برای سرویس‌دهی بیشتر و بهتر، شیوه‌ی اختصاص منابع به درخواست‌ها از اهمیت بسیاری برخوردار است. یکی از راهکارهای اختصاص منابع، استفاده از thread برای پردازش درخواست‌هاست. اما thread به‌خودی خود علاوه بر اختصاص منبع، مصرف‌کننده‌ی آن نیز هست. به زبان ساده‌تر، استفاده از thread، علی‌رغم اینکه می‌تواند به سرعت پردازش کمک کند، دارای سربار حافظه و پردازش است. این سربار به‌ویژه وقتی که زمان پردازش هر درخواست کم باشد، خود را نشان می‌دهد، زیرا زمان صرف‌شده برای ایجاد و مدیریت هر thread نسبت به زمان پردازش درخواست قابل توجه می‌شود. بر همین اساس توصیه می‌شود که از thread برای پردازش‌هایی استفاده شود که زمان قابل توجهی را به خود اختصاص می‌دهد و نه کارهای کوچک.

با توجه به مطالب گفته شده، مسائل پیش رو را مرور می‌کنیم: نخست،‌ ما با درخواست‌های پرتعدادی روبرو هستیم که قریب به اتفاق آنها زمان کمی برای پردازش نیاز دارند، اما قرار گرفتن آنها در صف پردازش زمان قابل توجهی را به خود اختصاص می‌دهد. دوم، با توجه به منابع محدود در دسترس، ما نیاز داریم که این منابع را به شیوه‌ای مناسب به درخواست‌ها اختصاص دهیم تا تمام درخواست‌ها در کوتاه‌ترین زمان ممکن پردازش شوند. سوم، ممکن است نیاز داشته باشیم که درخواست‌ها را بر اساس درجه‌بندی و اولویت آنها پردازش کنیم، به طوری که درخواست‌های حیاتی و فوری زمان کمتری را نسبت به درخواست‌های زمان‌بر و کم اهمیت در صف پردازش صرف کنند. این مقاله برای دستیابی به این اهداف راهکاری را پیاده‌سازی می‌کند که به thread pool موسوم است.

Read More

padlock from bloodykissatnight.deviantart.com

داده‌ساختارهای بدون قفل

توسط | مقالات فنی | ۴ نظر
[مطالبی که در ادامه می‌آید در سطح پیشرفته و نیازمند آشنایی خواننده با مفهوم «چندریسگی» و زبان برنامه‌سازی «سی پلاس پلاس» است.]

امروزه، کمتر کسی هست که در برنامه‌نویسی، اصطلاحات «پردازش چندریسه۱» یا «پردازش موازی۲» به گوشش نخورده باشد. پس از بازار داغ رقابت تولیدکننده‌های پردازنده برای افزایش سرعت پردازش تولیداتشان، در یک دهه‌ی اخیر این رقابت به تولید پردازنده‌هایی با تعداد پردازنده‌های بیشتر معطوف شد. البته تولید چنین پردازنده‌هایی سابقه‌ای دیرینه داشت، اما مدتی طول کشید تا به بازار رایانه‌های شخصی راه پیدا کند. با ظهور پردازنده‌های چندهسته‌ای، عموم برنامه‌نویس‌ها به تولید نرم‌افزارهای جدید یا بازتولید نرم‌افزارهای قدیم با قابلیت استفاده از این ویژگی پردازنده‌های نوین روی آوردند. اما علی‌رغم زیبایی و جذابیت آنچه پیش رو داشتند، تولید چنین نرم‌افزارهایی سختی خاص خودش را داشت که بزرگترین معضل آن با عنوان «کنترل دسترسی به داده‌های مشترک۳» شناخته می‌شود.

حافظه‌ی داخلی رایانه‌های شخصی راهکاری را برای کنترل دسترسی پردازه‌ها به داده‌های مشترک ارائه نمی‌کنند، که این امر در تعدد خواندن و نوشتن، به سرعت موجب خراب شدن داده‌ها می‌شود. برای حل این مشکل، سازوکارهایی ایجاد شده‌اند که به «قفل۴»، «میوتکس۵» یا «حصار حافظه۶» موسومند. استفاده از این سازوکارها، علاوه بر سربار محاسباتی زیاد، نیاز به دقت مضاعفی دارد تا از بروز اشتباهات ناشی از پیچیدگی به کار بردن آنها پرهیز شود. یافتن و جلوگیری از بروز این اشتباهات به هیچ عنوان کار ساده‌ای نیست، به گونه‌ای که توسعه‌دهندگان غالباً راه حل‌های «بدون قفل۷» را، اگر وجود داشته باشند، ترجیح می‌دهند. اما متأسفانه روش مشخصی برای توسعه‌ی الگوریتم‌های بدون قفل شناخته نشده‌است، به همین دلیل رویکرد ساده‌تر دیگری توسعه داده شده‌است که این امر را برای برنامه‌نویسان تسهیل می‌کند: «داده‌ساختارهای بدون قفل».

Read More

می‌خواهید از آخرین اخبار تاد مطلع باشید؟ ما را روی فیس‌بوک دنبال کنید