مقاله انگلیسی رایگان (PDF)

ترجمه فارسی رایگان (PDF)

خرید ترجمه با فرمت ورد

بخشی از ترجمه فارسی مقاله:

مقدمه
باتوجه به پیچیدگی روزافزون سازمانی،چشم اندازهای مختلفی توسط دانشمندان ومتخصصان اجتماعی،متخصصین مدیریت ومهندسین که باهمفکری هم سعی دردریافت آنالیز وفهم فاکتورهای مختلف موثر دردنیای سازمانی داشته اند،تعریف شده است.
سازمانها سیستم های پویا ودینامیکی هستند که درمحیط های پیچیده اجرا وبااستفاده ازخود آگاهی وتوانایی آن درانتقال وسازگاری ،به تغییرات واکنش نشان می دهند .شکست درسازگاری به تداخل منجرمی شود مکانیزم های انتطباق وسازگاری به بررسی کل سازمان جهت حفظ عملکرد وتداوم آن نیازدارند که بتواند همه ی جوانب مختلف سازمان را به یک دستگاه مناسب ویکپارچه ای پیوند بزندکه انطباق وترکیب هراجزای رادر یک سازمان تداومی بهمرا داشته باشد.
بااین وجود،این”چیز”که بخشها واعضای سازمان رابهم مرتبط می سازد،تنها یک ایده است که به شفاف سازی وتقیق نیازدارد تابه یک مفهوم عینی تجسم پیدا کند،واز رویکردهای قبلی ومفاهیم شناخته شده ومدلها نیزبهره مند شود.
Tribolet,Pascoa استفاده از مفاهیم سازمان هواپیمایی،برمبنای تشبیه پروازیاکنترل سازمان ،اجرا،سازمان تجاری،مفاهیم مشابه به منظور دست یابی به چابکی وتیزی هواپیما درزمان نزدیک به واقعی ،مطرح می کند.یک هواپیما همانند یک سازمان دارای چسبی است که اعضا وبخشهای آنرادریک سازمان یکپارچه به هم متصل می کند.
بااین وجود،هرگاه مابه یک چیزی فکرمی کنیم که قسمتهای مختلفی رابهم متصل میکند که متعلق به فرهنگ دنیاست،درواقع به راینه و سیستم عامل آن فکرمیکنیم.درحقیقت ،رایانه ازاجزایی تشکیل شده وسیستم عامل چیزی است که این اعضا وبخشهایی راکه رایانه رابه یک سازمان یکپارچه تبدیل می کند،بهم متصل می کند.Tanenbaum بیان می کند که”یک رایانه شامل یک یا چند پردازشکر،حافظه اصلی،دیسک ها،پرینترها،کیبورد ،موس ،صفحه نمایش،اتصالات شبکه ای و ابزار ورودی وخروجی مختلف می باشد وروی هم رفته یک سیستم پیچیده است”
نویسنده نیزبیان می کند که”مدیریت همه این اجزاءواستفاده بهینه ازآنها یک کارسیارچالش انگیزی است. به همین دلیل ،رایانه ها به یک لایه ی نرم افزاری تحت عنوان سیستم عامل مجهز است که وظیفه ی آن فراهم آوردن برنامه هایی با مدل ساده تر ،تمیزتروبهتر رایانه ای برای کاربروهمچنین مدیریت همه منابع می باشد.”
دراین مقاله بخش 2رایانه وسیستم عاملهارا معرفی می کند،
بخش 3پایه ها واصول مفهوم پرواز سازمان واجزای آن ونیازبه هدایت نزدیک زمان واقعی معرفی می کند.
بخش 4مدلهای DEMO را طراحی میکند واصول تئوری معرفی می کند .
بخش5رویکردی برای ایجاد سیستم عامل سازمانی مطرح می کند،
بخش 6 نتیجه گیری و بخش 7توصیه های تحقیقات آینده راارائه می دهد.
بخش دوم:
2-رایانه وسیستم عاملها
براساس shelly&vermaat یک رایانه می تواند به عنوان یک ابزار الکترونیکی تعریف شود که تحت کنترل دستورالعملهای ذخیره شده در حافظه خود عمل میکند ،که می تواند داده ها(ورودی)رادریافت کند،آنها براساس قوانین خاص پردازش کند(پردازش)،ونتایج راارائه دهد(خروجی)ونتایج رابرای استفاده آینده ذخیره کند(ذخیره سازی)،ورودی پردازش ،خروجی وذخیره سازی 4عمل اصلی رایانه ای می باشند.
برای اجرای عملیات ،یک رایانه به دو ابزار مهم واصلی :
1)سخت افزار:مجموعه ای از عناصرالکتریکی و الکترونیکی ومکانیکی
2)نرم افزار:که به آن برنامه هم میگویند،شامل یک سری از دستورالعملهای مرتبط که برای اهداف رایجی سازمان دهی شده اند وبه رایانه دستورمی دهد که چه عملی راانجام و چطور انجام بدهد،می باشد.
علاوه براین ،رایانه به4اجزای اصلی تقسیم می شود:
-ابزارورودی
-پردازشگر
-حافظه
-دستگاههای جانبی(خروجی ،ذخیره و ابزار ارتباطی)
از آنجاییکه رایانه هاتوسط انسان به عنوان کارابران مورد استفاده قرارمی گیرد ،سیستم عامل (os)یک برنامه نرم افزاری است که به عنوان یک واسطه بین کاربر رایانه و سخت افزار رایانه عمل می کند.
Tanenbaum اظهار می کند که OS مجموعه ای ازمنابع است که به انسان کمک می کند تا از عهده پیچیدگی برآید.silberschatz &Galvin سه هدف اصلی برای OS مطرح می کند:
1-اجرای برنامه های کاربرو حل آسان مشکلات کاربر
2-استفاده ازسیستم رایانه رابرای کاربر اسان میکند
3-ازسخت افزاررایانه به شیوه ای کاراآمد استفاده می کند.
نویسندگان کاربران (افراد،دستگاه ها ودیگر رایانه ها)رابه عنوان اجزای سیستم رایانه درنظر می گیرد .برای فهم جوامع ازOS ،مفاهیم پایه به شکل زیر ارائه می شوند:
پروسه ها ،فضاههای آدرس،فایل ها،حفاظت،جلد(تفسیرکننده های دستور)وفرمانهای (CALL)سیستم.OS یکپارچه دارای ساختار زیر میباشد:
1)یک برنامه اصلی که خدمات درخواستی رااعمال و اجرامیکند.
2)مجموعه ای ازرویکردهای خدمات که فرمان های سیستم رااجرا می کند.
3)مجموعه ای ازرویکردها ی ابزاری که به رویکردهای خدمات کمک می کند
Silberschatz&Galvin ،OSرا به 3 جزءتقسیم میکند:
1-تخصیص گرمنابع که منابع رامدیریت وتخصیص می دهد
2-برنامه کترل که اجزای برنامه های کاربروعمل ابزارI/O راکنترل می کند
3-Kernel برنامه ای که همه وقت اجرا می شود.

بخشی از مقاله انگلیسی:

1. Introduction

Given the increasing organizational complexity, several perspectives have been defined by social scientists, management scientists and engineers that have come together in a shared effort to capture, analyze and understand the multitude of factors that affect the organizational world. Organizations are dynamic systems that run in complex environments and need to react to changes, by increasing its self-awareness and its ability to transform and adapt. Failure to adapt can lead to disruption. Adaptation mechanisms need to consider the wholeness of the organization to maintain its viability and performance. To manage this complexity, organizations need “something” that can tie all different aspects of the organization into a seamlessly running machine guaranteeing that all these parts come together in a viable and performative organization. However, that “something” that glues the organization parts, being only an idea that needs clarification and research in order to be materialized into a tangible concept, can benefit from previous approaches and known concepts, theories and models. Páscoa and Tribolet1,2,3 proposed the use of the flying aircraft organization concepts, based on the metaphor “Flying the Organization”, implementing, within the business organization, the same concepts in order to attain the aircraft agility in near-real time. An aircraft, like an organization, possesses the glue that ties its components together in a seamlessly viable organization. However, when we think of “something” that glues different parts together, that already belongs to the world culture, we think on the computer and its operating system. In fact, the computer has components and the operating system is the “something” that glues these components making the computer a viable and performative organization. Tanenbaum4 states that “A modern computer consists of one or more processors, some main memory, disks, printers, a keyboard, a mouse, a display, network interfaces, and various other input/output devices. All in all, a complex system”. The author further states that “managing all these components and using them optimally is an exceedingly challenging job. For this reason, computers are equipped with a layer of software called the operating system, whose job is to provide user programs with a better, simpler, cleaner, model of the computer and to handle managing all the resources”. The document is structured as follows: section 2 introduces the Computer and Operating Systems; section 3 presents the foundations for the Flying the Organization concept, its components and the need for near real time steering; section 4 outlines DEMO models and presents its theoretical foundations; section 5 proposes an approach to devising the organizational operating system; section 6 concludes and section 7 presents future research recommendations.

2. Computer and Operating Systems

According to Shelly & Vermaat5 a computer can be defined as an “electronic device, operating under the control of instructions stored in its own memory, that can accept data (input), process the data according to specified rules (process), produce results (output), and store the results (storage) for future use”. Input, process, output and storage are the four basic computer operations. To perform operations, a computer needs two main utilities: i) hardware, a collection of electric, electronic and mechanical components; ii) software, also called a program, consists of a series of related instructions, organized for a common purpose, that tells the computer what tasks to perform and how to perform them. Furthermore, the computer is divided into four main components: input devices, processor, memory and peripherals (output, storage and communication devices). As computers are used by humans, acting as users, an operating system (OS) is a software program that “acts as an intermediary between a user of a computer and the computer hardware”5 . Tanenbaum4 states that OS provide a clean abstract set of resources that helps humans to coop with complexity. Silberschatz & Galvin6 propose three main goals for the OS: i) execute user programs and make solving user problems easier; ii) make the computer system convenient to use; iii) use the computer hardware in an efficient manner. The authors consider users (people, machines, other computers) to be computer system components. To provide comprehensive understanding about OS, basic concepts are provided such as: processes, address spaces, files, protection, shell (command interpreters) and system calls. The monolithic basic OS has the following structure: i) a main program that invokes the requested service; ii) a set of service procedures that carry out the system calls; iii) a set of utility procedures that help the service procedures. Silberschatz & Galvin6 divide the OS into three components: i) resource allocator that manages and allocates resources; ii) control program that controls the execution of user programs and operation of I/O devices: iii) kernel, the one program running at all times (all else being application programs). 

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

قابلیت به کار گیری به مفید بودن مدل داخل چارچوب محصولات مختلف نرم افزاری (اندازه، ساختار، توابع) اشاره دارد، محیط گسترده تولید، محیط های عملیاتی گوناگون و فازهای مختلف چرخه حیات.
سادگی. تشکیل یافته از سهولت در جمع آوری داده است که برای شخصی سازی بیشتر مدل ضروری تلقی میشود. همچنین به سادگی مفهومی نیز اشاره دارد که در آن ناظران مدل (مهندسان نرم افزار، مدیران پروژه و متخصصان قابلیت اتکا و سایرین) میتواند طبیعت مدل و برانگاشت آن را درک کنند و مورد استفاده اش برای یک مشکل خاص را تعیین نمایند و همچنین میزانی که در آن مدل در کاربرد مشخص اش از واقعیت جدا میشود. جدا از این مورد، سادگی شامل سادگی در پیاده سازی نیز میشود، به طریقی که مدل میتواند ابزاری کارآمد در مدیریت و مهندسی نرم افزار شود.
سهولت در اندازه گیری پارامترها. این جنبه تعداد پارامترهای مورد نیاز مدل و درجه سختی مرتبط در تخمین شان را لحاظ میکند.
حساس نبودن به نویز. جنبه ای که به ظرفیت مدل جهت انجام دقیق پیش بینی ها اشاره دارد، حتی زمانی که داده شکست ناقص یا حاوی ابهام باشد.
گوئل (گوئل 1985) پیشنهاد میکند پیش از اعمال یک مدل، خطا ها باید به صورت مستقل ارزیابی شوند، بسته به زمان تقویمی، زمان اجرا یا دفعات اجرای برنامه.
گوئل (گوئل 1985) عقیده دارد پیش از اعمال یک مدل، ارزیابی خطاهایش باید مورد مطالعه قرار گیرند، با استناد به زمان تقویمی، اجرا و یا دفعات اجرا. پس متغیرهای مهمی را میتوان انتخاب کرد و گرایش بدست آمده برای یک کلاس خاص از مدل نیز از همین راه است. پس از تخمین، پارامترهای مدل در فاز اول انتخاب میشود، یک تست مطابقت مبتنی بر مدل داده اجرا میشود (تصویر 1). اگر مدل سازگار باشد، معیارهای تخمین گر هم محاسبه خواهند شد و تصمیمات مرتبط با تکمیل یا تداوم تست کردن اتخاذ میشود. طبق تصویر 1، گام تعیین کننده در مورد اعمال مدل سنخیت آن است و نه مقایسه بین مقادیر تخمین زده شده و واقعی.
تکنیک های موجود برای ارزیابی یک مدل در این بخش مورد بررسی قرار گرفته اند، در چارت-U فاکتور بایس و گزارش شباهت محتاطانه تنها زمانی به کار گرفته میشوند که نمونه های رویداد وجود داشته باشند. در مورد نارسایی های نرم افزار باید گفت حداقل برخی از ایرادات نرم افزاری باید رخ داده و مورد بررسی قرار گیرند. در مورد دستگاه های برنامه پذیر قابل اتکا در حال کار نیز باید گفت این فرض کمی غیر واقعی خواهد بود. پس این روش ها بیشتر برای مدل های در حال رشد قابلیت اتکای نرم افزار کارآیی دارند، که به طور عمده مرحله پیشبرد چرخه حیات یک نرم افزار را نشان میدهد.

2.1. چارت-U
روش های دیگری هم برای اعتبارسنجی و مقایسه مدل ها وجود دارد، از جمله شباهت اعتبار-متقابل (بائت 1998). چارت-U برای سنجش نزدیک بوده مقدار تابع تعیین توزیع تجمعی بدیهی به مقدار توزیع واقعی به کار میرود (بر اساس مشاهدات موجود). مشخص است که متغیر تصادفی توزیع یکنواخت در بازه های مختلف دارد. پس اگر دستاوردها (برای مثال زمان شکست) مشاهده و محاسبه گردد، پس باید یک دستاورد از متغیر تصادفی واحد باشد. هرگونه انحراف از این یکنواخت بودن نشان دهنده انحراف خواهد بود.
برای پیدا کردن انحرافات (در صورت وجود) تابع توزیع نمونه از مشاهدات تبدیل شده به کار میرود. نمودار یک تابع پلکانی است که از تعداد بازه ها تشکیل یافته است. پس یک تابع پلکانی صعودی است که در هر گام بر روی یک مقدار از بعد افقی نوشته میشود.
هر چقدر این نمودار به خط شیب نزدیک باشد، نزدیکتر خواهد بود. در طرف دیگر، هرگونه انحراف سیستماتیک از شیب یکنواخت نشان دهنده ابهام در توزیع احتمال است.
این مفاهیم را میتوان به عنوان معیار عملیاتی نیز در نظر گرفت، آنهم از طریق یافتن فاصله کولموگروف (انحراف عمودی بیشینه دقیق) بین خط پیش بینی دقیق از منحنی 1 و دیاگرام متاثیر از آن.
2.2. چارت-Y
چارت-Y درجه وابستگی مدل گرایش را نشان میدهد؛ برای مثال یک مدل میتواند در مورد تعداد نارسایی های نرم افزار در ابتدا بدبین باشد، بعضی اوقات بسیار خوشبین.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

2. تاریخچه مختصری از سرریزهای بافر
سرریزهای بافر یک آسیب‌پذیری کلاسیک با تاریخچه طولانی در سوء استفاده‌ها هستند [4]. از لحاظ مفهومی، حمله به آنها نسبتا آسان است. به‌عنوان‌مثال، یک برنامه آسیب‌پذیر ممکن است داده‌ها را از شبکه خوانده و در یک بافر جای دهد. سپس، با فرض اینکه برنامه فاقد مرزهای بررسی کافی برای محدود کردن اندازه ورودی داده است، مهاجم می‌تواند در پایان بافر حافظه را مجددا بازنویسی کند. در نتیجه، حالت بحرانی جریان کنترل، مانند بازگشت آدرس یا اشاره‌گر تابع، می‌تواند دستکاری کرد. سرریزهای پشته بافر تمایل ویژه‌ای به بازگشت آدرس‌ها به طور ضمنی در نزدیکی حافظه به‌دلیل عملکرد فراخوانی دارند. با این‌حال، حملاتی که بافر را مورد هدف قرار می‌دهند عملی می‌باشند [5].
در روزهای اولیه سرریز بافر پشته، برای یک مهاجم بسیاررایج بود که شامل کدهای مخرب به‌عنوان بخشی مورد استفاده در سرریز بافر باشد. در نتیجه، مهاجم می‌تواند به سادگی آدرس برگشت را به مکانی شناخته شده در مجموعه پشته نگاشت کند و دستورالعمل‌هایی را که در بافر ارائه شده‌اند اجرا کند. چنین حملاتی نظیر “تزریق کد” دیگر در ماشین‌های معاصر امکان‌پذیر نیست چرا که پردازنده‌های مدرن و سیستم عامل‌ها در حال حاضر توانایی علامت زدن صفحات حافظه داده‌ها به‌عنوان غیر قابل اجرا (به‌عنوان مثال، NX در x86) را دارند. در نتیجه، اگر یک مهاجم سعی در اجرای کد بر روی پشته داشته باشد، تنها یک استثنا اتفاق خواهد افتاد.
روش های نوآورانه، که با نام برنامه‌نویسی بازگشت‌گرا (ROP) شناخته شده‌اند [1]، برای دفاع در برابر شکست‌ها بر روی حافظه‌های غیر قابل اجرا توسعه داده شده‌اند. که از طریق ایجاد ارتباط کوتاه با هم کار می‌کنند که در حال حاضر در فضای آدرس برنامه وجود دارند. چنین قطعه کدهایی، با نام gadgets شناخته می‌شوند و می‌توانند به شکل محاسبات دلخواه ترکیب شوند. در نتیجه، مهاجمان می‌توانند از ROP برای به‌دست آوردن کنترل برنامه بدون هیچ وابستگی به کد تزریق شده استفاده کنند. گاهی اوقات تغییرات ساده در ROP امکان‌پذیر است. به‌عنوان مثال، با حملات بازگشت به libc، عملکرد یک کتابخانه سطح بالا را می‌توان به‌عنوان آدرس برگشت استفاده کرد. به‌طورخاص، تابع ()system برای مهاجمان مفید است زیرا می‌توانند کد دلخواه خود را تنها با یک آرگومان اجرا کنند [6]. این حملات در سیستم‌های 32 بیتی که در آن آرگومان‌ها بر روی پشته عمل می‌کند بسیار مؤثر بودند و در حال حاضر تحت کنترل مهاجم هستند. بر روی سیستم‌های 64 بیتی، که در آن آرگومان‌ها بر روی رجیسترها عمل می‌کند، gadget های اضافی برای ثبت جمعیت مورد نیاز است.
چیدمان تصادفی فضای آدرس‌دهی(ASLR)، [7] و [8] به‌عنوان یک دفاع در برابر حملات سرریز بافر معرفی می‌شود و با تصادفی‌سازی محل کد و بخش‌های داده در فضای آدرس فرآیند کار می‌کند. در بسیاری از پیاده‌سازی‌های تصادفی قطعه کد که تنها به کتابخانه اعمال می‌شوند، تصادفی‌سازی پر فضای آدرس نیز ممکن است. ASLR یک چالش عمده برای مهاجمان ایجاد می‌کند چراکه مکان‌های آدرس کد (و یا حتی پشته) برای پیش‌بینی غیرممکن هستند. متاسفانه، بر روی سیستم عامل 32 بیتی، ASLR توسط تعدادی از بیت‌های موجود (معمولا 16) برای محدود تصادفی ایجاد می‌شود. در نتیجه، حملات brute-force کاملا موثر است [9]. با این‌حال، بر روی سیستم عامل 64 بیتی به‌طور معمول بیت تصادفی بسیاری وجود دارد که باید امکان‌پذیر باشد. در چنین مواردی، ASLR می‌تواند استفاده نشود، اما تنها زمانی که همراه با یک آسیب‌پذیری ناشی از نشت اطلاعات در مورد فضا آدرس‌دهی باشد، مانند فرمت رشته [10].
علاوه بر فضای آدرس بزرگتر برای ASLR و نیاز به ابزارهای اضافی برای پر کردن آرگومان‌ها، سیستم‌های 64بیتی یک عارضه سوم برای حملات هستند. زیرا معماری موجب محدودیت آدرس‌های مجازی به 48 بیت می‌شود، اشاره‌گر حافظه در سطح کاربر برای بایت‌های با ارزش صفر مورد نیاز است. این صفرها موجب ختم اولیه سرریزها با تکیه بر عملیات رشته مانند strcpy می‌شوند.
Canaries [11] دفاع مشترک در برابر حملات سرریز بافر است. Canaries نمی‌توانند از سرریزهای بافر جلوگیری کنند، اما می‌توانند سابقه و پایان برنامه را قبل از این که یک مهاجم بر جریان کنترل تاثیر بگذارد شناسایی کنند. مثلا، با پشته canaries، یک مقدار پنهان و نامعلوم، پیش از هر اشاره‌گر ذخیره شده و آدرس بازگشت تعیین می‌شود. سپس، هنگامی که یک تابع مجددا فراخوانی می‌شود، ارزش آن بررسی می‌شود تا از عدم تغییر آن اطمینان حاصل کند.
این امر می‌تواند از سرریز بافر پشته به دلیل سوء استفاده جلوگیری کند، زیرا یک مهاجم باید به‌درستی مقادیر پنهان را به منظور استفاده دقیق برنامه از آدرس برگشت بازنویسی کند. با‌این‌حال، فقط به‌عنوان ASLR، canaries می‌تواند از شکست در برابر آسیب‌پذیری‌های اضافی که از نشت اطلاعات در مورد مقادیر پنهان نشات می‌گیرد مقابله کند. طرح پشته حافظه می‌تواند یک ایده مهم برای پیاده‌سازی canaries باشد. یکی از رویکردهای شایع، قرار دادن تمام بافرها در بالای فریم است، بنابراین اگر سرریز اتفاق بیافتد بازنویسی مجدد متغیرها امکان‌پذیر نخواهد بود [12]. انگیزه‌ی این عمل محافظت از اشاره‌گر است زیرا گاهی اوقات می‌توان آنها را مجددا و به دلخواه بازنویسی استفاده کرد [13]. متاسفانه، canaries یک راه حل مناسب نیست، حتی با اقدامات احتیاطی، گاهی اوقات ساختار یک سرریز بافر می‌تواند به مهاجم این اجازه را بدهد که به حالت بحرانی به طور مستقیم دسترسی یابد، به‌عنوان مثال، اشاره‌گر ناامنی که در yaSSL اتفاق افتاد [3].

3. آموزش ROP
قبل از بحث در مورد روش کورکورانه ROP، ابتدا با ROP آشنا می‌شویم. سوء استفاده مدرن به شدت به ROP متکی است. هدف از ROP ساخت یک توالی است که معمولا براساس کد موجود عمل می‌کند. هنگامی که یک پوسته اجرا می‌شود، مهاجم می‌تواند دستورات بیشتری را برای ادامه حمله اجرا کند. شکل 1 shellcode معمولی را نشان می‌دهد که سوکت مهاجم را به ورودی استاندارد، خروجی، خطا و اجرای یک shell خط لوله می‌کند.
البته تزریق shellcode دیگر امکان‌پذیر نیست چرا که این روزها حافظه قابل نوشتن (به‌عنوان مثال، پشته) غیرقابل اجرا است، به همین ترتیب ROP بجای آن استفاده می‌شود. شکل 2 نشان می‌دهد که چگونه ROP می‌تواند برای ایجاد shellcode که قبلا در شکل 1 نشان داده شده است استفاده شود. پشته سرریز می‌کند به‌طوری‌که آدرس تمام ابزارهای موجود در دنباله هستند. هر ابزار با بازگشت به‌طوری‌که ابزار بعدی بتواند اجرا شود به پایان می‌رسد.
در عمل، هر ابزار ROP یک دنباله کوتاه از دستورالعمل‌های خاتمه دستگاه با بازگشت خواهد بود.
اجرای یک پاسخ سیستم ساده مانند dup2 به چندین ابزار نیاز دارد چرا که آرگومان‌ها از ریجسترها عبود خواهند کرد. شکل 3 ابزارهای مورد نیاز برای dup2 را نشان می‌دهد. رجیستر RDI و RSI دو آرگومان سیستم فراخوانی، و RAX تعداد تماس سیستم را کنترل می‌کند. ریجسترها را می‌توان با استفاده از ابزارهای pop و قرار دادن مقادیر برای بارگذاری در پشته کنترل کرد. با وصل زنجیروار این ابزارها، shellcode کامل در نهایت ساخته می‌شود.

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

تسهیل فنی کاربران لبه را قادر می سازد تا منابعی را برای یکدیگر فراهم کرده و از منابع یکدیگر استفاده نمایند. لازم است تا رایانش ابر اجتماعی از تعابیر آدرس شبکه (NAT) عبور کند، آدرس های IP غیر ثابت را (مخصوصا در مورد کاربران تلفن همراه) مدیریت کند و بهترین مفاهیم تلاش کیفیت خدمات را به حساب آورد. با وجودی که مفهوم ابر اجتماعی بر این فرض استوار است که کاربران یک شبکه اجتماعی تا حدی به یکدیگر اعتماد دارند، ایجاد رایانش ابر اجتماعی مستلزم امنیت کافی و مکانیسم های امنیتی برای محافظت از منابع در مقابل کاربرانی که به طور بالقوه بداندیش یا نالایق هستند و همچنین برای محافظت از کاربران در مقابل منابعی است که به طور بالقوه نامناسب هستند. می توان این مسئله را، همراه با نیاز برای حمایت از سیستم های عامل چندگانه، تا حدی از طریق مجازی سازی مورد بررسی قرار داد.
ساختارهای اجتماعی به اشتراک گذاری منابع رایانه ای در میان شبکه ای اجتماعی را تسهیل می سازد. به منظور استفاده از ساختارهای اجتماعی برای به اشتراک گذاری منابع، ابتدا کاربران باید دسترسی به شبکه اجتماعی خود را ممکن سازند و با داده های شبکه اجتماعی خود به سیستم عامل اعتماد کنند. به دلایل متعددی، وابسته ساختن تخصیص منابع به نکته دوگانه ارتباط دوستانه به خوبی طراحی نشده است. اول اینکه، ارتباطات اجتماعی تنها حاشیه هایی در یک نمودار نیستند. انواع مختلفی ازارتباطات وجود دارد (مثلا، خانواده، دوستان نزدیک، همکاران، آشنایان و غیره). دوم این که، کاربران مختلف به موقعیت های ارتباطی مختلف به مقادیر مختلفی اطمینان می کنند. سوم این که، افراد مختلف ویژگی ها و توانایی های مختلفی نیز دارند (مثلا از نظر قابل اعتماد بودن، میزان آمادگی)؛ برای مثال، کاربران ممکن است چنین فرض نمایند که دوستانی که به علوم کامپیوتری آشنایی دارند، به خاطر ارائه کردن منابع رایانه ای، بهتر یا تواناتر هستند. این سه بعد ارتباطی به این معنی است که ممکن است کاربران تمایلات خاصی در مورد کسانی داشته باشند که با آنان تعامل دارند و این تمایلات ممکن است برای نقش های کاربر و فراهم کننده متفاوت باشد. بنابراین، ابر اجتماعی مستلزم فراداده های اضافی برای استدلال در مورد نمودار اجتماعی و کاربران آن است تا طراحی سازوکاری ممکن باشد که بتواند تمایلات و برداشت های کاربران نسبت به یکدیگر را در نظر بگیرد. در اینجا، چالش اصلی طراحی شیوه هایی برای شناختن این تمایلات به صورت واضح از خود کاربر و یا به صورت ضمنی از پرونده های شبکه اجتماعی آنان است.
مدل اجتماعی – اقتصادی برای تخصیص منابع در میان رایانش ابر اجتماعی. با فرض بر این که مفهوم ابر اجتماعی بیشتر بر اشتراک گذاری توجه می کند تا فروش منابع، ما مدل های پولی را در نظر نمی گیریم. با این وجود، هنوز یک نظام (اقتصاد خرد) مورد نیاز است که به عنوان محل اتصال عرضه و تقاضا عمل نماید. کمبود یک جایگاه اقتصادی مشخص ایجاد رایانش ابر اجتماعی را تا حدی چالش برانگیز می سازد. به طور معمول، تخصیص منابع از طریق تبادلات پولی مبتنی بر ارزش گذاری های خصوصی است که کاربران انجام می دهند. این کار کاربران را ملزم می سازد تا در مورد ارزش منابع، و کارهای خود که می خواهند انجام دهند، بیندیشند که این مسئله به طور قابل توجهی انگیزه (های) آنان را تغییر می دهد. با استفاده از تمایل به اشتراک گذاری، زمینه اجتماعی تبادل اهمیت بیشتری پیدا می کند. با این حال، استفاده از تنها تمایل به اشتراک گذاری به عنوان ابزاری برای تعیین تخصیص منابع همراه با پیوندهای اجتماعی کاربر تا حد زیادی فرایند تخصیص دادن را پیچیده تر می سازد. در اینجا، مسئله اصلی تخصیص دادن نیست، بلکه چگونگی تخصیص منابع به صورت مؤثر می باشد. به عبارت دیگر، جلوگیری رایانه ای از شیوه های تخصیص فشرده، و در عین حال، حفظ تعادل بین تخصیص منابع و نقدینگی سیستم عامل.
تسهیل سیستم عامل رایانش ابر کامیپیوتری. از آن جا که مدل وابسته به اشتراک گذاری (ایثارگونه) منابع می باشد، مفهوم مدل درآمدی برای حمایت از سیستم عامل کارکردهای اساسی آن مشکل زا است. نباید کاربران برای خدمات ارائه شده توسط سیستم عامل ابر اجتماعی هزینه ای پرداخت کنند. با این حال، سیستم عامل مستلزم منابع رایانه ای برای عمل به وظیفه خود می باشد. از آن جا که در این مقاله، این چالش مورد بررسی قرار نمی گیرد، در عوض به [16] رجوع می کنیم که در آن مدلی جمعی برای ایجاد سیستم عامل ابر اجتماعی ارائه می دهیم. مدل جمعی حاکی از آن است که منابع نه تنها با هدف به اشتراک گذاری، بلکه برای حمایت از خود سیستم عامل به شکل منابع زیربنایی فراهم می شوند.

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

2.2.1 سیستم عامل رایانش ابر اجتماعی
همانند هر مدل ابری دیگری، لازم است تا سیستم عامل کارکردهای بنیادین خود (مدیریت کاربر، تخصیص منابع و غیره) را هماهنگ و تسهیل سازد. تصویر 1 معماری سطح بالای رایانش ابر اجتماعی و مؤلفه های اصلی آن را نشان می دهد که در زیر توضیح داده می شوند:
اتاق پایاپای اجتماعی سیستم نهادی شده اقتصاد خرد است که چگونگی تخصیص عرضه به تقاضا را تعریف می کند. اسمیت مؤلفه های اصلی نظام اقتصاد خرد را با اهداف تبادل در [17] تعریف نمود. با این حال، این تعریف در درجه اول به تبادلات وابسته به پول مربوط می شود که در اینجا مورد بحث ما نمی باشد. بنابراین، یک اتاق پایاپای اجتماعی تعریف زیر را ارائه می دهد: تفاهم نامه های مورد استفاده برای تخصیص منابع توزیع شده، قوانین تبادل؛ به عبارت دیگر، چه کسی می تواند شرکت کند، و با چه کسی تبادل انجام می دهند، رسمیت ادن به یک یا چند سازوکار تخصیص. بنابراین، اتاق پایاپای اجتماعی مرکز اصلی سیستم بوده که در آن تمام اطلاعات مربوط به کاربران، تمایلات آنان برای به اشتراک گذاری، و منابع عرضه و تقاضای آنها نگهداری می شود. به همین دلیل، این اتاق مستلزم دو پایگاه داده است: برای به دست آوردن نودار اجتماعی کاربران و همچنین تمایلات آنان برای به اشتراک گذاری، و یک مدیر منابع برای پیگیری حفظ، در دسترس بودن و تخصیص منابع.
میان افزاری به منظور فراهم ساختن ترکیب اصلی منابع، مجازی سازی منابع و سازوکارهای امنیتی برای آماده سازی و به کار گیری منابع. این ابزار باید تفاهم نامه های مورد نیاز کاربران برای پیوستن و ترک کردن سیستم را نیز تعریف نماید. به این دلایل، سیاتل [12]، [18] را انتخاب کردیم، چون تا حد زیادی کارآمدی های مورد نیاز را فراهمی می کند. با این حال، سیاتل نمی تواند منابع خود را بر اساس پیوندهای اجتماعی تخصیص داده و در نتیجه، گسترش داده شد.
تطبیق دهنده اجتماعی – فنی، که در مورد ما فیس بوک است، برای دسترسی به جنبه های مورد نیاز شبکه های اجتماعی کاربران مورد نیاز بوده و به عنوان ابزاری برای اثبات، مثلا از طریق پیوند با فیس بوک، عمل می کند. زمانی که شبکه اجتماعی کاربری از طریق تطبیق دهنده اجتماعی – فنی حاصل شود، اتاق پایاپای اجتماعی نیازمند دانستن تمایلات به اشتراک گذاری کاربر است تا بتواند تخصیص منابع را تسهیل سازد. بنابراین، واحد تمایلاتی مورد نیاز است که کارآمدی مورد نیاز برای به دست آوردن و بازنمایی به اشتراک گذاری تمایلات را فراهم سازد. بسیاری از جنبه های تطبیق دهنده اجتماعی – فنی به بررسی دقیقی نیاز دارند و شیوه های زیادی را می توان برای به دست آوردن تمایلات به کار برد که در قسمت 2.2.2 به بحث در موردآنها می پردازیم.
ساز و کارهای انطباق پیاده سازی اجتماعی – فنی سیستم اقتصاد خرد اتاق پایاپای اجتماعی است. آنها تخصیص های مناسب منابع را از طریق تمایلات به اشتراک گذاری کاربران از میان شبکه اجتماعی آنان تعیین می کنند که در قسمت های 2.2.3 و 3.3.1 مورد بحث قرار می گیرند.
منابع رایانه ای وقف فنی کاربران است که برای ابر اجتماعی منابعی را تامین و از آن استفاده نیز می کند. در اینجا، منابع تا حد زیادی مستلزم رایانه های شخصی، سِروِرها یا دسته ها است. با این وجود، متوجه می شویم که مورد آخر برای کاربر عادی غیرمحتمل است. تصور می کنیم همین طور که صنایع رایانه ای به سرمایه گذاری خود در برنامه های رایانه ای تلفن همراه ادامه دهد، در آینده چنین ابزارهایی می تواند در ابر رایانه ای نیز ارائه شود. با این حال، امروزه، موضوعاتی نظیر ثبات شبکه و دوام باتری مانع گنجاندن آنها می شود. با این وجود، علی رغم این که محققان پیشرفت های زیادی در این حوزه کرده اند، به [19] رجوع کنید.

بررسی زمان واقعی سیستم عامل: RTOS

The Survey Of Real Time Operating System: Rtos

Abstract

The paper discusses the literature survey of RTOS (Real Time Operating Systems) and its contributions to the embedded world. RTOS is defined as a system in which the correctness of the system does not depend only on the logical results of computation but also on the time at which the results are produced. It has to perform critical tasks on priority basis keeping the context switching time minimum. It is often associated with few misconceptions & we have tried to throw some light on it. Since last 20 years, RTOS is undergoing continuous evolution and has resulted into development of many commercial RTOS products. We have selected few commercial RTOS of different categories of real-time applications and have discussed its real-time features. A comparison of the commercial RTOSs’ is presented. We conclude by discussing the results of the survey and comparing the RTOS based on performance parameters.

I- Introduction

Last few years have seen the remarkable rise in the demand of embedded systems in human affairs. It has made its mark in every field ranging personal home affairs, business, and process automation in industries, communications, entertainment and defense. As we know, embedded system is a combination of hardware and software and perhaps other mechanical parts designed to perform a specific function [1]. We realize its contribution in making our life comfortable and safe, for that it has to satisfy time and memory constraints. The performance of these systems depends on the OS which are used. Most of these systems require RTOS for such a precise task. The first RTOS was produced more than 20 years ago by DEC for the PDP family of machines, which then undergone the process of evolution. Real time operating System (RTOS), as the name suggests provides a deadline associated with tasks and an RTOS adheres to this deadline as missing a deadline can cause affects ranging from undesired to catastrophic. RTOS must be deterministic and pre-emptive. An RTOS is effective and allows the real-time applications to be designed and expanded more easily whilst meeting the performances required. Abbreviations and Acronyms: IPC – Interprocess communication MPU – Microprocessor unit DEC – Digital Equipment Corporation LoC– Lines of code An operating system generally consists of two parts: kernel space (kernel mode) and user space (user mode).The basic part of any OS and which acts as a bridge between applications and the actual data processing at the hardware level, is a kernel. A kernel can provide the lowest-level abstraction layer for the resources (especially processors and I/O devices).

VII- CONCLUSIONS

Real time applications have become popular these days due to the complexity in the system. To meet those complexities, the developers are given the invariable task of making the real time software. There are quite large numbers of RTOS available in the market and one does get confused as to which one to select; such that it provides the efficient embedded systems design in terms of cost, power consumption, reliability, speed etc. Ranking RTOS is a tricky and difficult because there are so many good choices are available in the market. The developer can choose either commercial RTOS (44% developers are using) or opensource RTOS (20) or internally developed RTOS (17 %). From comparison and study of these selected commercial RTOS, we can infer that – RTAI and VxWorks provide a wide range of supported platforms. RTAI, an Open-source RTOS is most suited for small applications, such as robotics and medical devices. Whereas, VxWorks is dominant in highly complex and high performance applications. When we have many interrupts VxWorks is the better pick & it is faster than RTAI. Applications which are getting number of interrupts continuously in such case VxWorks should be preferred. Interrupts will tend to increase when number of inputs is applied to the RTOS simultaneously. In terms of message send/receive latency, RTAI is a better performer than VxWorks by a marginal difference. As mentioned earlier, these figures might vary to a large extent depending on the IPC implementation (IPC can be implemented using shared memory).

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

A) سیستم عامل زمان واقعی (RTOS)
“سیستم عامل‌های زمان واقعی برای پیش‌بینی، بهره‌وری استفاده می‌شوند و شامل ویژگی‌هایی برای حمایت محدودیت زمان هستند” [5]. در RTOS تمام وظایف باید به‌موقع (در زمان انتشار) منتشر شود و همچنین باید قبل از زمان خاص به نام مهلت به پایان برسد. وظیفه‌ی زمان واقعی اگر با شکست مواجه شود می‌تواند این محدودیت زمانی را برآورده نکند [6]. به‌عبارت دیگر، نقض محدودیت زمان‌بندی در RTOS منجر به شکست سیستم می‌شود. به‌منظور تجزیه‌وتحلیل RTOS و گارانتی سیستم ایمنی، قطعات داخلی باید دقیقا تعریف شده و همچنین رفتار آنها باید قابل پیش‌بینی باشد.
به عنوان مثال XOberon یک RTOS کوچک است که قابلیت پیش‌بینی و ایمنی را همزمان فراهم می‌کند [7].

B) مهلت نرم، سفت و سخت
آخرین مهلت، ویژگی مهمی برای وظایف در RTOS زمانی که نتایج باید قبل از آن تولید شود است. اگر نتیجه پس از مهلت به‌دست آید، مهلت به‌عنوان نرم طبقه‌بندی می‌شود، در غیر این‌صورت سفت است. اگر عواقب شدیدی به‌وجود آید می‌تواند یک مهلت سفت از دست برود، در این‌صورت سخت نامیده می‌شود [8]. به‌عبارت دیگر نقض مهلت نتایج سفت در شکست و نقض مهلت نتایج سخت در فاجعه است.
نیازمندی‌های مختلف RTOS سخت و نرم نقش مهمی در طراحی سیستم دارد. اگر سیستم، محدودیت زمان واقعی سخت داشته باشد، طراح به‌صرف زمان زیادی برای گارانتی ایمنی و قابلیت پیش‌بینی و همچنین گارانتی همه‌ی محدودیت‌های زمانی (مهلت) نیاز خواهد داشت. در صورتی که شرایط زمان‌بندی سیستم نرم باشد، یک سیستم بهترین تلاش برای رسیدن به محدودیت زمان را دارد و همچنین دارای حداقل افت کیفیت است درحالی‌که نقض محدودیت زمان باید طراحی شود. بازیکنان رسانه قابل حمل و کنفرانس‌های ویدئویی آنلاین نمونه‌هایی از سیستم در زمان واقعی نرم هستند. نمونه‌هایی از سیستم‌های بلادرنگ سخت شامل سیستم درایو‌های سیم در خودرو، سیستم پرواز با سیم در ارتباطات هوایی، سیستم‌های کنترل موشک و سیستم‌های فضایی مستقل هستند.
سیستم عامل‌های زمان واقعی سخت بر روی محدودیت‌های زمانبندی به‌عنوان مهم‌ترین مسئله در طراحی سیستم تمرکز دارند و نسبت به تحمل‌پذیری خطا به‌همان اندازه‌ی محدودیت زمان توجه ندارند. از آنجا که وقوع شکست در RTOS هم که باعث تولید نتایج نادرست به دلیل محاسبات اشتباه و یا باعث تولید نتایج نامعتبر می‌شود زیرا مهلت از دست رفته است، اجرای تکنیک تحمل‌پذیری خطا باید در طراحی سیستم در نظر گرفته شود. در این مقاله چند ویژگی اصلی RTOS همراه با تعدادی از تکنیک‌های تحمل‌پذیری خطا ارائه شده است که می‌تواند در هر یک از ویژگی‌ها استفاده شود.

3. ویژگی RTOSS، و فنون تحمل‌پذیری خطا
در بخش‌های قبلی، به اهمیت پیاده‌سازی تکنیک‌های تحمل‌پذیری خطا در RTOS، به ویژه کسانی که در حوزه ایمنی بحرانی کار می‌کنند مورد بحث قرار گرفت. در این بخش، تعدادی از ویژگی‌های RTOS همراه با برخی از تکنیک‌های تحمل‌پذیری خطا ارائه شده است که می‌تواند برای هر یک از ویژگی‌ها استفاده شود.

A) مدیریت حافظه
به‌منظور حفاظت از اجزای سیستم عامل، مستعد ابتلا به شکست، تحمل‌پذیری خطا با حفاظت از حافظه آغاز می‌شود. زیرا رفتار برنامه به داده‌ها در حافظه بستگی دارد وجود خطا در این داده‌ها باعث خطا و شکست در برنامه می‌شود.
از آنجا که انعطاف‌پذیری و قابلیت برنامه‌های کاربردی در حال افزایش است و همچنین آنها نیاز به دسترسی پویا به حافظه دارند، الگوریتم تخصیص ذخیره‌سازی پویا (DSA) نقش مهمی در سیستم عامل‌ها بازی می‌کند. علاوه بر انعطاف‌پذیری، برنامه‌های زمان واقعی نیاز به پیش‌بینی بیش از حد دارند، به‌عنوان مثال حافظه باید به صورت پویا در یک زمان محدود و از پیش تعیین شده اداره می شود. استفاده از DSA منجر به عدم قطعیت در RTOS، به دلیل زمان پاسخ نامحدود از الگوریتم DSA و مشکل تکه تکه شدن می‌شود. در [9] یک الگوریتم DSA با نام TLSF توسعه داده شده است که در RTOS به‌کار گرفته شده است. TLSF تخصیص صریح و تخصیص بلوک‌های حافظه با زمان‌بندی محدود و قابل قبول Ɵ (1) فراهم می‌کند. استفاده از بیت‌مپ ها و کمک بیت مپ روش دیگری برای تخصیص حافظه ایمن و قابل اعتماد است. این تکنیک توسط [10] که در RTEMS RTOS به کار گرفته شده است، معرفی می‌شود.
سیستم عامل‌ها از واحد مدیریت حافظه (MMU) برای اجرای وظایف در آدرس حافظه محافظت شده استفاده می‌کنند. با این وجود برخی RTOS ها MMU و استفاده از آن را غیر فعال می‌کنند. [9] OSEK-VDX، μITRON و RTAI نمو‌ه هایی از چنین RTOS هایی هستند که MMU را غیرفعال می‌کنند [11]. با غیرفعال کردن MMU سیستم عامل و تمام فرایندها در فضای آدرس همان را اجرا می‌کنند و هر وظیفه، دسترسی به کدها و داده‌های سیستم عامل و فرآیندهای دیگر را دارد. ازاین‌رو اگر یک کد بد نوشته شود و یا یک اشکال در یک کد باشد، برای مثال در اشاره‌گر مدیریت، منجر به شکست در هسته می‌شود و در نتیجه سقوط سیستم عامل می‌شود. بدون حفاظت آدرس حافظه، همچنین برخی از اشکالات خطا می‌شود که به سختی قابل تشخیص است. به‌عنوان مثال در پردازنده‌های PowerPC، RAM معمولا در آدرس فیزیکی 0 واقع می‌شود، طوری که حتی یک ارجاع اشاره‌گر NULL ممکن است شناسایی شود [12]. به‌منظور جلوگیری از چنین شکستی، RTOS باید MMU استفاده کند. با فعال کردن MMU، هر زمان که پشته یک کار سرریز کرد، یک استثنا سرریز مطرح شده است و سیستم عامل اجرای وظیفه را متوقف می‌کند. به‌جای متوقف کردن اجرای وظیفه، سیستم عامل می‌تواند کار را به حالت تعلیق درآورد و مشکل محدودیت پشته توسط مهاجرت وظیفه سرریز شده به یک فضای آدرس حافظه جدید با ظرفیت بزرگتر، با توجه فضاهای محفوظ و بی‌قید و شرط و سپس اجرای دوباره وظیفه‌ی معلق را حل کند. طراح RTOS باید زمان مهاجرت به‌هنگام تجزیه‌وتحلیل سیستم را داشته باشد.
رفع اشکالات یکی از تکنیک‌های مهم در تحمل‌پذیری خطا [3] است. این روش را می‌توان برای حافظه هنگامی‌که یک فرآیند بارگذاری می‌شود به‌کار برد، سیستم عامل داده‌های آن و حالت‌ها را در بیش از یک مکان/حافظه (سه مکان/ TMR) تکرار می‌کند. هر زمان که وظیفه/حالت یک داده تغییر می‌کند، این تغییرات به همه کپی‌ها اعمال می‌شود. هر زمان که کار می‌خواهد شروع به خواندن داده‌ها از حافظه کند، یک کپی برای تعیین اینکه آیا داده‌ها سهوا تغییر و یا خراب نشده‌اند (به هر دلیل، مانند تابش یونی سنگین) و همچنین برای تعیین داده درست می تواند مورد استفاده قرار گیرد. افزونگی حافظه می‌تواند در هر دو سطح نرم‌افزار و سطح سخت‌افزار [13] پشتیبانی شود.
علاوه بر افزونگی، یک سیستم مدیریت حافظه مقاوم در برابر خطا را می‌توان با چهار مکانیزم همزمان ساخت: اولین مکانیسم ضبط که برای ضبط به‌روزرسانی حافظه (نوشتن) حوادث فعال می‌شود، ثانیا مکانیسم ضبط دوم که سوابق حداقل تعداد محدودی از حافظه را ضبط می‌کند، یک فعال‌کننده برای فعال کردن اولین مکانیسم ضبط در این رویداد از رخداد خطا و یک مکانیزم ادغام مجدد حافظه که توسط ادغام برخی از بخش‌هایی حافظه [14] برای بازیابی اطلاعات استفاده شده است. در این سیستم مدیریت حافظه، بازیابی خطا می‌تواند به سرعت و کارآمد با ادغام صفحات حافظه و با در نظر گرفتن به‌روزرسانی حافظه ورودی مشخص شده در مکانیزم ضبط اول و دوم انجام شود.
حافظه کد تصحیح خطا (حافظه ECC) ابزاری برای بهبود قابلیت اطمینان سیستم عامل از منظر حفاظت از حافظه است. حافظه ECC یک نوع از ذخیره‌سازی داده‌های کامپیوتر است که توانایی تشخیص و تصحیح انواع بسیاری از خطاهای داخلی داده را دارد. این حافظه به خطاهای تک بیتی مقاوم است: داده‌ای که از هر کلمه خوانده می‌شود همان داده است که در آن نوشته شده است، حتی اگر یک بیت به حالت اشتباه [15] باشد. برخی از حافظه‌های غیر ECC با برابری پشتیبانی اجازه می‌دهد تا اشتباهات شناسایی شود، اما قابل اصلاح نیست. قابلیت اطمینان یک RTOS مقاوم در برابر خطا با به کارگیری این نوع از حافظه بهبود یافته است. در مقابل این تکنیک مبتنی بر سخت‌افزار، روش‌های مبتنی بر نرم‌افزار تشخیص و تصحیح خطا در حافظه وجود دارد که [16] هر دو قابلیت اطمینان و انعطاف‌پذیری را دارا هستند.

B) ملاحظات هسته
تشخیص خطا را می‌توان با روش‌های سخت‌افزاری و یا نرم‌افزار انجام داد، از جمله عنوان “تشخیص خطای گذرا از طریق چند رشته به‌طور همزمان” [17] که به‌عنوان مثال از روش‌های نرم‌افزاری است. هسته RTOS مقاوم در برابر خطا باید مکانیزمی را رائه کند که هر زمان که خطا رخ می‌دهد، یک پیام به یک عامل فرستاده شود که وظیفه انجام برخی از انواع اقدامات بازیابی خطا را فراهم می‌کند. این عامل که به نام سرپرست شناخته شده است باید در یک فضای آدرس جدا شده اجرا شود، زیرا داده‌ها در فضای آدرس حاوی وظیفه معیوب ممکن است خراب شوند. به‎عنوان مثال در Nooks که یک زیر سیستم قابلیت اطمینان است، مدیر بازیابی Nooks یک عامل برای بازیابی خطا [18] است. VxWorks RTOS یک ساختار درختی برای مدیریت اطلاع خطا توسط اجزای سطح بالاتر در درخت سلسله مراتبی [19] است که توسط قطعات سیستم عامل تولید شده است. سرپرست وظیفه‌ی بازیابی کارهای خطادار را با استفاده از بهبود backward- Forward و یا شروع دوباره آن دارد. استراتژی بهبود انتخاب شده باید در تجزیه‌وتحلیل سیستم در نظر گرفته شده و تعریف شود.

میان افزار قابل پیکربندی برای سیستم های زمان-واقعی توزیع شده با وظایف متناوب و غیرمتناوب

Configurable Middleware for Distributed Real-Time Systems with Aperiodic and Periodic Tasks

چکیده 

سیستم های زمان-واقعی توزیع شده مختلف (DRS) باید رویدادهای متناوب و غیرمتناوب را تحت مجموعه ای متناوب از الزامات (شرایط) رفع و رجوع نمایند. در حالیکه میان افزار موجود مانند CORBA زمان-واقعی, به عنوان یک سیستم عامل برای سیستم های توزیع شده با محدودیت های زمانی نویدبخش بوده است, اما فاقد مکانیزم های پیکربندی انعطاف پذیری مورد نیاز برای مدیریت زمانبندی آسان سر هم پیوسته برای گستره وسیعی از DRS مختلف با رویدادهای متناوب و غیرمتناوب است. سهم اولیه این کار, طراحی, پیاده سازی, و ارزیابی عملکرد اولین خدمات میان افزار مولفه قابل پیکربندی برای کنترل پذیرش و تعادل بار رفع و رجوع رویداد متناوب و غیرمتناوب در DRS است. نتایج تجربی, نیاز و اثربخشی رویکرد میان افزار مولفه قابل پیکربندی ما را در حمایت از کاربردهای مختلف با رویدادهای متناوب و غیرمتناوب نشان می دهند و یک سیستم عامل نرم افزار انعطاف پذیر برای DRS با محدودیت های زمانبندی سر هم پیوسته را فراهم می کند.

Abstract

Different distributed real-time systems (DRS) must handle aperiodic and periodic events under diverse sets of requirements. While existing middleware such as Real-Time CORBA has shown promise as a platform for distributed systems with time constraints, it lacks flexible configuration mechanisms needed to manage end-to-end timing easily for a wide range of different DRS with both aperiodic and periodic events. The primary contribution of this work is the design, implementation, and performance evaluation of the first configurable component middleware services for admission control and load balancing of aperiodic and periodic event handling in DRS. Empirical results demonstrate the need for, and the effectiveness of, our configurable component middleware approach in supporting different applications with aperiodic and periodic events, and providing a flexible software platform for DRS with end-to-end timing constraints.

1 INTRODUCTION

MANY distributed real-time systems (DRS) must handle a mix of aperiodic and periodic events, including aperiodic events with end-to-end deadlines whose assurance is critical to the correct behavior of the system. Requirements for increased software productivity and quality motivate the use of open distributed object computing (DOC) middleware such as CORBA, rather than building applications entirely from scratch using proprietary methods. The use of CORBA middleware has increased significantly in DRS domains such as aerospace, telecommunications, medical systems, distributed interactive simulations, and computer-integrated manufacturing, which are also characterized by stringent quality of service (QoS) requirements [1]. For example, in an industrial plant monitoring system, an aperiodic alert may be generated when a series of periodic sensor readings meets certain hazard detection criteria. This alert must be processed on multiple processors within an end-to-end deadline, e.g., to put an industrial process into a fail-safe mode. User inputs and other sensor readings may trigger other real-time aperiodic events. While traditional real-time middleware solutions such as Real-Time CORBA [2] and Real-Time Java [3] have shown promise as distributed software platforms for systems with time constraints, existing middleware systems lack the flexibility needed to support DRS with diverse application semantics and requirements. For example, load balancing is an effective mechanism for handling variable real-time workloads in a DRS. However, its suitability for DRS highly depends on their application semantics. Some digital control algorithms (e.g., proportional-integral-derivative control) for physical systems are stateful and hence not amenable for frequent task reallocation caused by load balancing, while others (e.g., proportional control) do not have such limitations. Similarly, job skipping (skipping the processing of certain instances of a periodic task) is useful for dealing with transient system overload. While job skipping is not suitable for certain critical control applications in which missing one job may cause catastrophic consequences on the controlled system, other applications ranging from video reception to telecommunications may be able to tolerate varying degrees of job skipping [4]. Therefore, a key open challenge for DRS is to develop a flexible middleware infrastructure that can be easily configured to support the diverse requirements of different DRS. Specifically, middleware services such as load balancing and admission control must support a variety of alternative strategies (algorithms and inputs corresponding to those algorithms). Furthermore, the configuration of those strategies must be supported in a flexible yet principled way, so that system developers are able to explore alternative configurations without choosing invalid configurations by mistake. Providing middleware services with configurable strategies, thus, faces several important challenges: 1) services must be able to provide configurable strategies, and configuration tools must be added or extended to allow configuration of those strategies; 2) the specific criteria that distinguish which service strategies are preferable must be identified, and applications must be categorized according to those criteria; and 3) appropriate combinations of services’ strategies must be identified for each such application category, according to its characteristic criteria. To address these challenges, and thus to enhance support for diverse DRS with aperiodic and periodic events, we have designed and implemented a new set of component middleware services including end-to-end event scheduling, admission control, and load balancing. We have also developed configuration tools to integrate these service components for each particular application according to its specific criteria. Research contributions. In this work, we have 1. developed what is to our knowledge the first set of configurable component middleware services supporting multiple admission control and load balancing strategies for handling aperiodic and periodic events; 2. developed a novel component configuration preparser and interfaces to configure real-time admission control and load balancing services flexibly at system deployment time; 3. defined categories of distributed real-time applications according to specific characteristics, and related them to suitable combinations of strategies for our services; and 4. provided a case study that applies different configurable services to a domain with both aperiodic and periodic events, offers empirical evidence of the overheads involved and the trade-offs among service configurations, and demonstrates the effectiveness of our approach in that domain. Our work, thus, significantly enhances the applicability of real-time middleware as a flexible infrastructure for DRS. Section 2 introduces the middleware systems and scheduling theory underlying our approach. Sections 3-5 present our middleware architecture, configurable strategies, and component implementations for supporting endto-end event handling in DRS. Section 6 describes our new configuration engine extensions, which can flexibly configure different strategies for our services according to each application’s requirements. Section 7 evaluates the performance of our approach, including trade-offs among different service strategy combinations, and characterizes the overheads introduced by our approach. Section 8 presents a survey of related work, and we offer concluding remarks in Section 9.

عملکرد چندپردازنده های تراشه چند رشته ای و پیامدها برای طراحی سیستم عامل

Performance of multithreaded chip multiprocessors and implications for operating system design

چکیده
1- مقدمه
2- سابقه و شبیه ساز
3- منابع تنگناهای عملکرد
3-1 خط لوله پردازنده
3-2 کش های پردازنده
4- برنامه ریزی BALANCE SET
4-1- مدلی برای نسبت از دست رفتن کش
4-2 زمانبندی تنظیم شده-تعادل
4-3 نتایج
5- پیاده سازی زمانبند
6- کار مرتبط
7- نتایج

چکیده

چکیده
طراحی یک سیستم عامل اغلب از معماری سخت افزار هدف تحت تاثیر قرار می گیرد. در حالی که معماری های تک پردازنده و چند پردازنده به خوبی درک شده اند، چندپردازنده های تراشه چند رشته ای (CMT) به خوبی درک نشده اند–یک نسل جدید از پردازنده های طراحی شده برای بهبود عملکرد کاربردهای حافظه-محور. فقط اولین سیستم های مجهز به پردازنده های CMT در دسترس است، به طوری که در حال حاضر درک چگونگی به دست آوردن بهترین عملکرد از چنین سیستم هایی برای ما بسیار مهم است.
هدف از کار ما, درک اصول عملکرد CMT و شناسایی مفاهیم طراحی سیستم عامل است. ما نحوه تاثیرپذیری عملکرد یک پردازنده CMT در کشاکش خط لوله پردازنده، حافظه نهان داده L1 و حافظه نهان L2 را تحلیل نموده ایم، و رویکردهای سیستم عامل برای مدیریت این منابع عملکرد حیاتی را مورد بررسی قرار داده ایم. پس از مشخص شدن این مورد که کشاکش برای کش (حافظه نهان) L2 می تواند بیشترین تاثیر منفی را بر روی عملکرد پردازنده داشته باشد، بهبود عملکرد بالقوه را تعیین نموده ایم که می تواند از برنامه ریزی سیستم عامل آگاه از-L2 به دست آید. ما یک سیاست برنامه ریزی را بر اساس اصل تعادل-تنظیم شده ارزیابی نمودیم و متوجه شدیم که این مقوله دارای پتانسیل برای کاهش نسبت های از دست رفتگی در L2 تا 19-37٪ و بهبود توان عملیاتی پردازنده تا 27-45٪ است. دستیابی به بهبود مشابه در سخت افزار به دو برابر شدن اندازه کش L2 نیاز دارد.

1. مقدمه
یک سیستم عامل, یک لایه انتزاعی بین سخت افزار و نرم افزار فراهم می کند. کار آن, در معرض قرار دادن توان سخت افزار به کاربردها و در عین حال پنهان کردن پیچیدگی های آن است. جای تعجب نیست که معماری سخت افزار, طراحی سیستم عامل را تحت تاثیر قرار می دهد. موضوع طراحی سیستم عامل برای پردازنده های معمولی در گذشته بررسی شده است. این مقاله با بررسی زمینه طراحی سیستم عامل برای یک خانواده از پردازنده ها شروع می شود: چندپردازنده های تراشه چند رشته ای (CMT).
6. کار مرتبط
کار قبلی, الگوریتم های زمانبندی را برای پردازنده های تک هسته ای SMT پیشنهاد داده است که موجب بهبود زمان پاسخ سیستم تا 17% شده اند [1,2,12]. این الگوریتم ها شامل نمونه برداری فضای زمانبندی های ممکن و استفاده از زمانبندی هایی می شوند که به بهترین شکل عمل می کنند. این روش می تواند به طور مجازی بدون سربار پیاده سازی شود, اما به حمایت سخت افزاری نیاز دارد. الگوریتم زمانبندی ما به این علت متفاوت است که از مدلسازی برای پیش بینی بهترین زمانبندی استفاده می کند. مدلسازی برای نمونه برداری در هنگام بزرگ بودن فضای نمونه ترجیح داده می شود, مثلاً روی یک سیستم مجهز شده با چندین زمینه رشته (یعنی یک پردازنده CMT) که صدها رشته را ایجاد می کند. مقایسه اثربخشی و هزینه های روش پیشنهادی در مطالعه SMT برای ما روی یک پیکربندی CMT بزرگ جالب خواهد بود. امیدواریم ایده ها از مطالعه پیگیرانه در مورد گنجاندن اولویت ها در زمانبند آگاه از SMT [2] را برای بهبود انصاف زمانبند خود اعمال نماییم.

Abstract

An operating system’s design is often influenced by the architecture of the target hardware. While uniprocessor and multiprocessor architectures are well understood, such is not the case for multithreaded chip multiprocessors (CMT) – a new generation of processors designed to improve performance of memory-intensive applications. The first systems equipped with CMT processors are just becoming available, so it is critical that we now understand how to obtain the best performance from such systems.

The goal of our work is to understand the fundamentals of CMT performance and identify the implications for operating system design. We have analyzed how the performance of a CMT processor is affected by contention for the processor pipeline, the L1 data cache, and the L2 cache, and have investigated operating system approaches to the management of these performance-critical resources. Having found that contention for the L2 cache can have the greatest negative impact on processor performance, we have quantified the potential performance improvement that can be achieved from L2-aware OS scheduling. We evaluated a scheduling policy based on the balance-set principle and found that it has a potential to reduce miss ratios in the L2 by 19-37% and improve processor throughput by 27-45%. To achieve a similar improvement in hardware requires doubling the size of the L2 cache.

1. INTRODUCTION

An operating system provides a layer of abstraction between the hardware and the software. Its job is to expose the power of the hardware to applications, while hiding its complexities. It is no surprise that the architecture of the hardware influences the design of the operating system. The subject of operating system design for conventional processors has been addressed in the past. This paper begins to investigate the area of operating system design for a new family of processors: multithreaded chip multiprocessors (CMT).

6. RELATED WORK

Previous work has proposed scheduling algorithms for single-core SMT processors that have been shown to improve system response time by 17% [1, 2, 12]. These algorithms involved sampling the space of possible schedules and using the ones that performed the best. This method can be implemented with virtually no overhead but requires hardware support. Our scheduling algorithm is different in that it uses modeling to predict the best schedule. Modeling may be preferable to sampling when the sample space becomes very large, such as on a system equipped with dozens of thread contexts (i.e., a CMT processor) running hundreds of threads. It would be interesting to compare the effectiveness and costs of the method proposed in the SMT study to ours on a large CMT configuration. We are also hoping to apply ideas from the follow-up study on incorporating priorities into the SMT-aware scheduler [2] to improve fairness of our scheduler..

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

2. کارهای پیشین
نمونه های تجاری پردازنده های شبکه بسیار هستند [3، 6، 7، 10]. یک پردازنده شبکه معمولا به صورت چند پردازنده یک تراشه ای با اجزایI/O باکارایی بالا پیاده سازی میشود که برای پردازش بسته بهینه سازی شده است. به طور خاص، NPها یک معماری مناسب تر نسبت به ایستگاه کاری معمولی یا پردازنده های سرور، برای رسیدگی به این حجم کاری ارائه میکند. نیاز به یک معماری تخصصی به دلیل منحصر به فرد بودن حجم کاریNP است که تحت سلطه بسیاری از تسک های کوچک و عملیات I/O با پهنای باند زیاد است [21]. یک جایگزین دیگر برای پیاده سازی توابع پردازش بسته ، دستگاه های قابل برنامه ریزی منطقی هستند به عنوان مثال، مدارهاس مجتمع دیجیتال قابل برنامه ریزی (FPGA ها)، که بیشتر مناسب برخی از توابع پردازش به سبک جریان داده می باشند [1، 18].
الزامات طراحی برای پشتیبانی زمان اجرا در سیستم های مبتنی بر FPGA بسیار شبیه بهNP های معمولی هستند و در نتیجه انتظار می رود نتایج کار ما نیز به همان اندازه در این دامنه قابل اجرا باشد. به منظور دستیابی به کارایی لازم سرعت خطی روزافزون و توابع پردازش بسته به طور فزاینده پیچیده، هر دو NP و FPGA از روش موازی سازی استفاده میکنند که بطور ذاتی در حجم کاری این سیستم ها وجود دارد. به طور کلی، بسته ها را تا زمانی می توان به صورت موازی پردازش کرد که متعلق به جریان مشابه باشند. توابع پردازشی در یک بسته نیز می توانند بصورت موازی برای کاهش تاخیر بسته اجرا شوند. این امر منجر به سیستمهای NP با پردازش موازی زیاد و موتورهای پردازشی میشود. برای برنامه نویسی چنین سیستمی، چند زبان برنامه نویسی خاص دامنه توسعه یافته است.اینتل به طور مشترک با پروژه Shangri-La در دانشگاه تگزاس در آستین Baker را توسعه داده است [5]. پروژه MESCAL در دانشگاه برکلی NP-Click را توسعه داده [17]، که براساس روتر ماژولار Click می باشد[8].
در پروژه NEPAL [12]، Memik و همکاران یک سیستم زمان اجرا ارائه کردند که اجرای برنامه های کاربردی بر روی یک پردازنده شبکه را کنترل می کند. برنامه های کاربردی با استفاده از API NEPAL به ماژولهایی در سطح تسک تقسیم شده و که صورت پویا به هسته های اجرا نگاشت میشوند.همچنین یک سطح اضافی ترجمه در طی تبدیل کد برنامه به ماژول وجود دارد.
تجزیه و تحلیل تکنیک های زمان اجرا به ترکیبی از الگوریتم های تخصیص ابتکاری محدود شده است. Teja [19] یک محیط برنامه نویسی تجاری برای خانواده پردازنده های شبکه اینتل IXP می باشد. در حالی که آنها یک سیستم عامل پردازش شبکه ارائه میکنند (NPOS)، هم Teja و هم NEPAL برای ساده سازی روند برنامه نویسی یک برنامه واحد و با هدف استفاده مجدد کد در تمام سیستم عاملها طراحی شده اند. ما از توانایی انطباق سریع با برنامه های متعدد بر روی همان سیستم پردازنده شبکه پشتیبانی نمی شود.
بااینکه کارهای زیادی بر روی مکانیزم های مدیریت پویای برنامه های متعدد وجود ندارد، پژوهش هایی بر روی الگوریتمهای تطبیق و زمانبندی پردازنده های شبکه برای صرفه جویی در مصرف انرژی انجام گرفته است. Kokku و همکاران مسائل مربوط به طراحی محیط زمان اجرا، شبیه به آنچه که در اینجا ارائه میشود، را بررسی کرده اند[9]، اما آنها برنامه های پارتیشن بندی شده که روی چند پردازنده شبکه توزیع شده اند را در نظر نگرفته اند. در عوض، فرض شده است که یک برنامه کامل به یک پردازنده تک هسته ای نگاشت میشود.

3. سیستم عامل پردازنده شبکه
اصطلاح “سیستم عامل” اغلب در زمینه ایستگاه های کاری کامپیوتری استفاده می شود. مسئولیت های چنین سیستم عاملی، مدیریت منابع سخت افزاری و جداکردن کاربران از یکدیگر است. هدف بهینه سازی معمولا به حداقل رساندن زمان اجرای یک وظیفه می باشد (وظیفه ای که کاربر فعلا با آن کار میکند). قابل توجه است که اهداف یک سیستم عامل برای پردازنده های شبکه بسیار متفاوت هستند. در یک پردازنده شبکه، تمام برنامه ها توسط یک موجودیت اداری کنترل شده و بهینه سازی با هدف به حداکثر رساندن توان عملیاتی کل سیستم انجام میگیرد.

3.1 تفاوت ها با سیستم عامل های ایستگاه کاری
در زیر جزئیات تفاوت بین سیستم عامل های پردازنده شبکه و سیستم عامل های معمولی لیست شده است:
• تفکیک کنترل و مسیر داده. این جدایی به شرایط پردازنده اشاره دارد نه به شرایط شبکه. برای رسیدن به توان عملیاتی بالا درNP ها، مطالعات متعددی نشان داده اند که پیاده سازی تعداد بیشتری از موتورهای پردازشی ساده تر نسبت به موتورهای کمتر ولی قوی تر مقرون به صرفه تر است این پردازنده های ساده قابلیت اجرای وظایف کنترلی پیچیده در بالای بسته پردازش وظایف ندارد. در طراحی NP های امروزی، کنترل بر روی یک پردازنده کنترل جداگانه پیاده سازی میشود. با توجه به تفکیک بین “کلاس های” پردازنده، داشتن یک ساختار کنترلی واضح تر از یک سیستم عامل معمولی ضروریست.
• تعامل محدود. کاربران به طور مستقیم با NP و یا سیستم عامل آن تعامل ندارند. حداکثر، بعضی اوقات برنامه های کاربردی نصب شده و حذف میشوند. این بدان معنا نیست که یک کاربر نمی تواند تنظیمات یک NP را تغییر دهد (به عنوان مثال، قوانین به روز رسانی یک نرم افزار دیوار آتش)، اما متغیر کلیدی در این سیستم الگوهای ترافیکی ست که تعیین می کند چه پردازشی باید اتفاق بیافتد.
• نظم و سادگی نرم افزارها. یکی از جنبه های برجسته پردازش شبکه این است که پردازش مسیر داده در بسته های منفرد انجام می گیرد. این بدان معنی است که تسک های پردازش بسته معمولا به علت قیود زمان واقعی تحمیلی توسط بسته های مداوم پیچیدگی ندارند. در نتیجه، تقاضای پردازش کم است (از چند صد تا چند هزار دستورالعمل) [16]. علاوه بر این، مسیر اجرای یک برنامه در بسیاری از موارد مشابه بوده و تنها برای تعداد کمی از موارد دیگر متفاوت است. بنابراین تجزیه و تحلیل جزئی برنامه های کاربردی پردازش بسته برای یافتن نگاشتهای خوب پردازنده امکان پذیر است.
• پردازش غالب بر مدیریت منبع. سیستم عامل های معمولی نیاز به پیاده سازی تعدادی توابع مختلف دارند: زمانبندی پردازنده، مدیریت حافظه، جداسازی نرم افزار، انتزاع منابع سخت افزاری، و غیره. در سیستم های پردازنده شبکه، این چالش ها تحت سلطه مدیریت منابع پردازشی است. تنوع منابع سخت افزاری محدود بوده و بسیاری از آنها به طور مستقیم توسط نرم افزار کنترل می شوند. همچنین، حافظه معمولا بطور ایستا تخصیص داده میشود تا از رفتار قطعی زمان اجرا اطمینان حاصل شود. این مساله ممکن است در آینده تغییر کند همانگونه که برنامه های کاربردی شبکه پیچیده تر شده و سیستم عاملهای پردازنده شبکه بیشتر شبیه به سیستم عامل های معمولی میشوند. در این کار، ما روی جنبه های پردازشی سیستم عامل تمرکز داریم.
• عدم تفکیک فضای کاربر/ فضای کرنل. تمامی توابع در یک پردازنده شبکه توسط یک موجودیت اداری مشابه کنترل می شود. هیچ جدایی واضحی میان فضای کاربر و فضای کرنل وجود ندارد. در عوض، عملیات بین کنترل و مسیر داده تقسیم شده است. در نتیجه مکانیزم های محافظت قدیمی به طور معمول در سیستم های عامل پردازنده شبکه اجرا نمی شوند.

3.2 ملاحظات طراحی
با توجه به تفاوت های زیاد و قابل توجه بین یک سیستم عامل معمولی و یک پردازنده شبکه، به اعتقاد ما کشف برخی از مسائل اساسی مربوط به طراحی که در زمینه سیستم عامل های پردازنده شبکه با آن سروکار داریم، حائز اهمیت است. پرسش هایی که از این اکتشاف بوجود می آیند عبارتند از:
• چگونه برنامه های کاربردی به صورت پویا بر روی پردازنده شبکه نصب و حذف میشوند؟
• چگونه می توان برنامه های کاربردی جهت استفاده از سخت افزار های زیربنایی چندپردازنده را پارتیشن بندی و نگاشت کرد؟
• چگونه باید سیستم عامل را با تغییرات ترافیکی شبکه که نیاز به پیکربندی های مختلفی دارد منطبق نمود؟
• میزان و سطح سازگاری چقدر است؟
به منظور بررسی صحیح جنبه های طراحی سیستم عامل، فرض میکنیم یک رویکرد عملیاتی جامع همانند شکل 1 فرض می کنیم. چهار مرحله اساسی که برای پشتیبانی زمان اجرا سیستم های پردازنده شبکه لازم است وجود دارد: تحلیل نرم افزار ، مشخصات ترافیکی، نگاشت حجم کار، و سازگاری . یک مساله اساسی وجود دارد آنچه که باید بصورت آفلاین انجام شود (به عنوان مثال، در طول توسعه نرم افزار) و آنچه که باید (و می تواند) در طول زمان اجرا انجام شود.

مقاله انگلیسی رایگان

ترجمه فارسی رایگان 

بخشی از ترجمه فارسی مقاله:

قابلیت بازیافت و تمامیت داده با NTFS
NTFS یک سیستم پرونده قابل بازیافت است که پایداری یک نسخه را با استفاده از فن آوری بازیافت و ورودی داده استاندارد تضمین می کند . در زمان توقف یک دیسک ، NTFS ثبات را با استفاده از اجرای یک روش بازیافت که به اطلاعات ذخیره شده در یک فایل ثبت دست پیدا می کند ، ذخیره می کند .
روش باز یافت NTFS درست است . در حالی که این موضوع را که نسخه به یک مکان پایدار ذخیره شده را تضمین می کند . ورودی داده نیازمند حجم کوچکی از منابع است .
NTFS همچنین برای به حداقل رساندن تأثیرات یک بخش بد بر روی نسخه NTFS ، از تکنیکی به نام مسیر دهی دوباره گروهی استفاده می کند .
مهم
اگر ثبت راه انداز اصلی ( MBR ) یا بخش راه انداز خراب شد ، شما ممکن است قادر به دستیابی به اطلاعات روی نسخه نباشید .

بازیافت داده با استفاده از NTFS
NTFS هر عمل کاربردی I/O را یک فایل را روی نسخه NTFS اصلاح می کند ، به عنوان یک تبادل اطلاعات می بینید و با هر یک از آنها به عنوان یک واحد درست رفتار مي کند .
NTFS برای اطمینان از اینکه یک تبادل اطلاعات می تواند کامل شود یا به وضعیت قبلی برگردد ، برنامه های کاربردی یک تبادل اطلاعات را قبل از اینکه به دیسک نوشته شوند در یک فایل ثبت ، ضبط می کند . زمانی که یک تبادل کامل در فایل ثبت ضبط شد ، NTFS برنامه های کاربردی تبادل را بر روی مخزن نسخه انجام می دهد . پس از اینکه NTFS مخزن را به روز کرد ، تبادل را از طریق ضبط آن در یک فایل ثبت انجام می دهد .
زمانی که تبادل انجام شد ، NTFS مطمئن می شود که تمام تبادل بر روی نسخه ظاهر می شود . حتی اگر دیسک متوقف شود . در طول عمل بازیافت ، NTFS هر یک از تبادلات انجام شده ای را که در فایل ثبت یافت می شود دوباره انجام می شود دوباره انجام می دهد . پس NTFS تبادلی را در فایل ثبت تعیین محل می کند که در زمان توقف سیستم انجام نشده است . اصطلاحات تکمیل نشده از ورود به نسخه منع شده اند .
NTFS برای ورود تمام اطلاعات انجام نشده یا دوباره انجام شده برای یک تبادل از سرویس فایل ثبت استفاده می کند . NTFS از اطلاعات دوباره انجام شده برای تکرار تبادل استفاده می کند . اطلاعات انجام نشده NTFS را قادر می سازند که تبادلی را که ناتمام است و یا خطا دارد را انجام ندهد .
مهم
NTFS برای تضمین این موضوع که ساختار نسخه ایرادی ندارد ، از بازیافت و ورودی داده های تبلولی استفاده می کند . به همین خاطر پس از توقف سیستم ، تمام فایل های سیستم در دسترس باقی می مانند . با این وجود به خاطر توقف سیستم و یا یک کد بخش بد ، داده های کاربر می تواند از دست بروند .
مسیر دهی دوباره گروه
در هنگام خطای یک بخش بد ، NTFS فن آوری بازیافتی به نام مسیر دهی دوباره گروه را به کارمی برد. زمانی که ویندوز 2000 یک بخش بد را تشخیص می دهد ، NTFS به طور دینامیکی گروهی را که شامل بخش خراب هستند مسیر دهی دوباره کرده و گروه جدیدی را برای داده ها تعیین می کند . اگر در هنگام خواندن خطایی رخ داد ، NTFS خطایی را به برنامه در حال اجرا بر می گرداند و داده از بین می رود . اگر خطا در حین نوشتن روی دهد ، NTFS داده را در یک گروه جدید می نویسد و داده از بین نمی رود .
NTFS آدرس گروهی را که حاوی بخش معیوب است در فایل گروه معیوب قرار داده و بنابراین بخش معیوب دوباره استفاده نمی شود .
مهم
مسیر دهی دوباره به گروه یک پشتیبانی متفاوت نیست . زمانی که خطا تشخیص داده شد ، دیسک باید از نزدیک بازبینی شود و اگر فهرست تشخیص رشد کند باید دوباره جایگزین شود . این نوع خطا در ثبت رویداد نشان داده شده است .

بخشی از مقاله انگلیسی:

Data Integrity and Recoverability with NTFS

NTFS is a recoverable file system that guarantees the consistency of the volume by using standard transaction logging and recovery techniques. In the event of a disk failure, NTFS restores consistency by running a recovery procedure that accesses information stored in a log file. The NTFS recovery procedure is exact, guaranteeing that the volume is restored to a consistent state. Transaction logging requires a very small amount of overhead. NTFS ensures the integrity of all NTFS volumes by automatically performing HDD recovery operations the first time a program accesses an NTFS volume after the computer is restarted following a failure. NTFS also uses a technique called cluster remapping to minimize the effects of a bad sector on an NTFS volume.

Important

If either the master boot record (MBR) or boot sector is corrupted, you might not be able to access data on the volume.

Recovering Data with NTFS

NTFS views each I/O operation that modifies a system file on the NTFS volume as a transaction, and manages each one as an integral unit. Once started, the transaction is either completed or, in the event of a disk failure, rolled back (such as when the NTFS volume is returned to the state it was in before the transaction was initiated). To ensure that a transaction can be completed or rolled back, NTFS records the suboperations of a transaction in a log file before they are written to the disk. When a complete transaction is recorded in the log file, NTFS performs the suboperations of the transaction on the volume cache. After NTFS updates the cache, it commits the transaction by recording in the log file that the entire transaction is complete. Once a transaction is committed, NTFS ensures that the entire transaction appears on the volume, even if the disk fails. During recovery operations, NTFS redoes each committed transaction found in the log file. Then NTFS locates the transactions in the log file that were not committed at the time of the system failure and undoes each transaction suboperation recorded in the log file. Incomplete modifications to the volume are prohibited. NTFS uses the Log File service to log all redo and undo information for a transaction. NTFS uses the redo information to repeat the transaction. The undo information enables NTFS to undo transactions that are not complete or that have an error.

Important

NTFS uses transaction logging and recovery to guarantee that the volume structure is not corrupted. For this reason, all system files remain accessible after a system failure. However, user data can be lost because of a system failure or a bad sector.

Cluster Remapping

In the event of a bad-sector error, NTFS implements a recovery technique called cluster remapping. When Windows 2000 detects a badsector, NTFS dynamically remaps the cluster containing the bad sector and allocates a new cluster for the data. If the error occurred during a read, NTFS returns a read error to the calling program, and the data is lost. If the error occurs during a write, NTFS writes the data to the new cluster, and no data is lost. NTFS puts the address of the cluster containing the bad sector in its bad cluster file so the bad sector is not reused.

Important

Cluster remapping is not a backup alternative. Once errors are detected, the disk should be monitored closely and replaced if the defect list grows. This type of error is displayed in the Event Log.