سیستم عامل کوثر

سیستم عامل فارسی کوثر

سیستم عامل کوثر

سیستم عامل فارسی کوثر

سیستم عامل کوثر

سیستم عامل فارسی کوثر

طبقه بندی موضوعی
بایگانی
آخرین نظرات
نویسندگان
پیوندها

تبادل اطلاعات فنی - مدیریت و توسعه پروژه

ع. رضوانی | چهارشنبه, ۴ تیر ۱۳۹۳، ۰۱:۲۷ ب.ظ
بخش تخصصی برای این قسمت در نظر گفته شده است
و این قسمت دیگر بروز رسانی نمی شود.
بخش های تخصصی در بخش موضوعات قابل مشاهده هستند.

  • ع. رضوانی

نظرات  (۷۸)

  • ۰۴ تیر ۹۳ ، ۱۴:۳۳
  • عماد رضوانی
    • دوستی ایمیل زده:
    یک پیشنهاد دارم:
    پیشنهادم اینه که خوب حالا که شروع کردی مشکلی نیست ولی بیا یک برنامه ریزی مهندسی سیستم ابتدا انجام بده .خوب این یک پروژه است نیازمند برنامه ریزی چون که قراره توسعه پیدا کنه ، و کاری با پروژه های سایرین نداشته باش.برای برنامه ریزی مدل توسعه نرم افزار تعریف کن ، توی این مدل بیا مراحل توسعه تعریف کن بعد مدل توسعه رو گسترش بده ریسک های پروژه رو شناسایی کن.
    نظرات‌؟‌  بسط این روش؟
  • ۰۴ تیر ۹۳ ، ۱۵:۳۷
  • پویا شاهین فر
    • بهترین روش توسعه نرم افزار به نظر من همون آبشاری هست. باید همه چیز یکسری تجربه شه. بعد از تجربه یه دیزاین دیگه و بعد از چند بار از نوع نوشتن آخرش به دیزاین مورد نظر برسید.
    مدیریت دیسک و ... فقط زمانبر هست. یعنی یه زمان رو صرف می کنید‌(بدون کسب تجربه و کدینگ‌) و دوباره بعد از کدینگ متوجه ایردات پروژه میشید.
  • ۰۴ تیر ۹۳ ، ۱۵:۴۲
  • عماد رضوانی
    • نظر منم همینطوره. من اومدم اینطور برنامه ریزی کردم که اول ببینیم یک سیستم x86 چی ها داره و یکی یکی بصورت مختصر تست کنیم و بعد شروع به توسعه و سرهم کردم پروژه کنیم.
    از جمله ریسک هایی که متوجه یک پروژه سیستم عامل هست(مخصوصا در کشور ما)   کمبود نیرو دائم بر روی پروژه. باید یه جوری طرح ریزی کرد که بدون دخالت نفر اصلی توسعه همچنان ادامه داشته باشه. بهترین پیشنهاد هم فعلا آقای بنی طبا دادن که مربوط به SDK هست.
  • ۰۴ تیر ۹۳ ، ۱۹:۳۰
  • لونا
    • سلام
    آقا پویا میشه دلایلتون راجع به انتخاب مدل آبشاری در این پروژه را مطرح کنید.

    خوب اون مدل نه تنها سربار زیادی می طلبه ، ضمن اینکه رفت و برگشت ها برای پروژه زیاد از لحاظ زمان مقرون به صرفه نیست.ضمن اینکه باید مستند سازی دقیق انجام داده شود.
    ولی مثلاً استفاده از مدل چابک (agile) بهتر است چون که ابتدا گروه بدون مستند سازی شروع به ساخت ویرایش های مختلفی در طول توسعه نرم افزار می شود ، و ضمن اینکه این مدل از مدل افزایشی پشتیبانی کاملی می کند و دقیقاً براساس مدل افزایشی ساخته شده است و حتی امکان استفاده مجدد از مولفه ها را می دهد ، مثلاً طبق نظر IBM نسخه ها می تواند به صورت زیر دسته بندی شود:

    1- نسخه پیش آلفا: این نسخه داخل خود سازمان پروژه توسط افراد پروژه استفاده می شود و مشکلات آن برررسی و در طول چندین نسخه بتا رفع شود.
    2 - نسخه آلفا: این نسخه توسط نیز توسط افراد پروژه استفاده می شود.
    3 - نسخه بتا: این نسخه توسط چند مشتری استفاده شود.
    4 - نسخه RC یا RTM: این نسخه کامل و باگ های آن رفع شده است و منتشر می شود تا توسط طیف وسیعی از کاربران تایید شود.
    5 - نسخه GA: نسخه تایید شده و نهایی است.

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

    خوب اما بهترین حالت برای انتخاب مدل توسعه نرم افزار انتخاب مدل های ترکیبی است مثلاً در حال حاضر کمتر جایی است که فقط از مدل چابک یا آبشاری استفاده کند آنها از مدل های ترکیبی استفاده می کنند چون هرکدام مزایایی خاص خود را دارد مثلاً در مدل XP ، برنامه نویسان باهم کار می کنند و کارها طبقه بندی شده است و کارها به صورت سناریو (داستان) به برنامه نویسان داده می شود و مدل XP از مهندسی خواسته های خوبی برخوردار است که می تواند در تعریف و بازتعریف خواسته ها کمک زیادی کند.
    موضوع این است که در نهایت پروژه موارد زیر را ارضا کند:
    1 - قابلیت اطمینان
    2- امنیت
    3 - قابلیت توسعه و گسترش (نگه داری و پشتیبانی)
    4 - قابلیت پذیرش
  • ۰۴ تیر ۹۳ ، ۱۹:۵۵
  • عماد رضوانی
    • یکی از دوستان منم هم بحثش بر سر همین موضوع بود:  اسکرام !
    الان در مورد انتشار نسخه من اینطور عمل کردم که فکر کنم شاید نیاز به ویراش داشته باشه:
    1.  Development
    2.  HotFix
    3. Feature
    4. Release
    لونا نیاز به توضیح بیشتر هست.
  • ۰۴ تیر ۹۳ ، ۲۱:۲۵
  • لونا
    • اسکرام مدیریت چابک است و متدلوژی نیست.
    چابک مبتنی بر توسعه افزایشی است و دیدگاهی برای مستند سازی نداره.و معمولاً در قالب چند پیاده سازی به کاربر تحویل داده می شود همین کارو مایکروسافت روی نسخه ویندوز و سایر نرم افزارهایش انجام می دهد و نظرات کاربران را در مورد هر پیاده سازی تحویل می گیرد و باگ ها و نیازهای آینده را دسته بندی می کند و براساس مثلاً اولویت بندی خواسته ها ، نسخه بعدی را ارائه می دهد این عمل آنقدر تکرار می شود تا نسخه کامل و بدون باگ (یا با کمترین باگ) تحویل داده شود.اما انجام پروسه های قابلیت اطمینان در داخل آن معمولاً به روش های مختلفی و براساس تصمیم گیری گروه توسعه ممکن است انجام شود.و این هزینه مستند سازی را کاهش می دهد.یک جورایی حضور مشتری یا کاربر نهایی در توسعه سیستم است و نقش مهمی در توسعه نرم افزار دارد.حالا مهندسی خواسته ها در این پروسه تولید ، نقش مهمی دارد و معمولاً و شاید سخت تر از سایر مدل ها مانند مدل آبشاری و ... انجام شود زیرا هیچ مستندی تولید نمی شود.اما این مهندسی خواسته نیاز به مدیریت دقیق و کامل دارد که می تواند در مدل های افزایشی مانند چابک با استفاده از ابزارهای خودکار انجام شود.
    ببین این نسخه ها هر کدام باید آزمون های تعیین شده را انجام دهند تا مسائلی مانند:
    کارایی ، قابلیت اعتماد ، قابلیت توسعه و ... بررسی شود و برای نسخه های بعد تصمیم گیری کارشناسی شود.هر مرحله از آزمون باید شامل معادله ای برای تولید یک گراف هیستوگرام باشد که گراف باید تحلیل شود و برای آن تحلیل باید برنامه ریزی صورت گیرد در هر برنامه ریزی باید نقاط قوت و ضعف و ریسک و ... شناسایی شود ، البته این معیارها به عنوان دامنه تابع  باید به تابع داده شود و برد به عنوان نتیجه واقعی و codedomain به عنوان نتیجه اصلی ، خروجی گردد.
    مثلاً در قایلیت اطمینان باید تابع توزیع تجمعی در مورد خرابی ها داریم و همچین سایر توابع که تخمین وقوع شکست ها را بررسی می کند.به طور کلی نرخ شکست باید تعیین شود.
  • ۰۴ تیر ۹۳ ، ۲۱:۴۹
  • پویا شاهین فر
    • @لونا
    بابت کامنت تون داخل وبلاگم شاکی هستم. بگذریم

    1. وقت کافی  معمولا توی پروژه وجود نداره. مدلهای دیگه زمان زیادی رو لازم دارن و اکثر مراحل بدرد توسعه نمی خوره.

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

    3. کادر مجرب و یکسان وجود نداره و معمولا در اسکارم و ... نتیحه درستی حاصل نمیشه.
    پاسخ:
    @لونا
    بابت کامنت تون داخل وبلاگم شاکی هستم. بگذریم
    -------------------------------------------------------------
    توصیه میکنم حتما با ایمیل با هم در ارتباط باشین و مشکل رو حل کنید.( پویا واقعا برای آراکس زحمت کشیده و نباید زحمتش نادیده گرفته بشه).


  • ۰۴ تیر ۹۳ ، ۲۱:۵۱
  • عماد رضوانی
    • بسیار عالی. پیشنهاد برای شروع؟
    سوال دیگه اینه که هسته هایی مثل لینوکس چه متدولوژی پیش گرفتند؟‌! آیا gnu کمک بزرگی به لینوکس نبود؟ نباید ساختاری شبیه به gnu درست کنیم؟
  • ۰۴ تیر ۹۳ ، ۲۱:۵۷
  • عماد رضوانی
    • من تقریبا با پویا موافقم. اگر شرکت ثابتی داشتیم و کارمندها دید کافی و پای کار بودند شاید میشد خیلی دقیق بصورت متدولوژی پیش رفت.
    اینطور نیست؟
  • ۰۴ تیر ۹۳ ، ۲۲:۰۸
  • لونا
    • 1 - مگه شما برای پروژه زمانبندی انجام دادید و بر چه اساسی می گید که اکثراً بدرد نمی خورد در حالیکه مدعی هستید روش آبشاری بهترین مدل است.پس اگر پاسخ شما این باشد پس مایکروسافت و سایر گروها و شرکت ها هم اکنون دارند اشتباه می کنند.
    اگر مدیران پروژه زمانبندی را در اثنای امکان سنجی انجام دهند با هر مدلی که شروع کنید هیچ مسئله ای پیش نمیاد چون که زمانبندی گراف داره و نقاط بحرانی و عطف مسائل در اثنای شروع پروژه می گردد مگر اینکه مدیران پروژه هیچ دقتی روی کار نداشته باشند.
    2 - منظور از دید چیست اگر منظور شما نبود مستند است گروه توسعه افزایشی و چابک پاسخ های روشنی در مورد موضوع دادند.اینکه پیاده سازی زمان زیادی می بره کاملاً برای همه مدل ها بسط داره.حالا می خواد مدل آبشاری باشه یا افزایشی مانند چابک.خیلی دید اشتباهی به مدل چابک دارند و فکر می کنند مدل چابک فقط برای برنامه نویسان حرفه ای است و معمولاً مهندسی سیستم و نرم افزار هیچ جایگاهی در آن ندارد در حالیکه جایگاه دارد.
    3 - اگر شما نتایج درستی از اسکرام نگرفتید بر می گرده به طول پروسه هایی که انجام می دید و  به احتمال زیاد شما به عنوان مدیر ، ریسک های پروژه را در نظر نگرفتید و برای آن آزمون انجام ندادید و خروجی نهایتاً به درستی حاصل نمی شود.چقدر ریسک ها مهم نبودند که نتایج اشتباهی گرفتید.شما از چه ابزاری برای مدیریت پروژه استفاده کردید مثلاً Visual Studio نسخه Team Foundation دارای امکان مدیریت مبتنی بر اسکرام قوی و کاملی است.

    چرا از من شاکی هستی؟ من هیچ کاری نکردم.
  • ۰۴ تیر ۹۳ ، ۲۲:۱۱
  • لونا
    • شما بدون شرکت هم میتونید کار کنید که گفته با اسکرام و چابک حتماً باید شرکت باشه نرم افزارهایی مثل Visual Studio Team Foundation دارای امکان برنامه نویسی و توسعه و مدیریت آنلاین هستند.سایر ابزارهای دیگه برای پلت فرم های دیگه هم است.
  • ۰۴ تیر ۹۳ ، ۲۲:۲۰
  • لونا
    • لینوس توروالدز روی هسته MINIX دکتر تننباوم کار کرد و روی اون هسته بود که نتایج بهتری برای تولید هسته لینوکس گرفته شد.
  • ۰۴ تیر ۹۳ ، ۲۲:۳۷
  • عماد رضوانی
    • بله اطلاع دارم که روی minix کار کرده ....
    اما سوال اینجاست. چرا لینوکس باید اینقدر توسعه داده بشه ؟ چرا باید اینقدر آدم بشینن روش کار کنن ؟ اون روز چی شد که همه مسشتاق کار کردن روی هسته اون شدن ؟
    آیا چنین مدلی بازم هم میشه راه انداخت؟

    اون بنده خدا هم که اسکرام رو معرفی کرد VSTF کار بود.
  • ۰۴ تیر ۹۳ ، ۲۲:۳۸
  • m.j_banitaba
    • مشکل اصلی در مدیریت منابع است . ما در اینجا به شدت کمبود منابع انسانی است و در بحث منابع انسانی در ایران مشکل اصلی اینکه اصلا مشکل اصلی چیه . ما در ایران هنوز با اینکه مشکل اصلی چیه تفاهم نداریم بر فرض اینکه قبول هم بکنیم که مشکل اصلی چیه بر اساس مدلهایی که بر اساس منابع دیگران تنظیم شده پیش می رویم . 
    در اینجا به نظر من مسیله اصلی اینه که هر نفر نیروی متخصص ما چقدر وقت مفبد برای این پروژه دارد . اگر حقیقت رو بخواهین این زمان حدود ده دقیقه مطالعه و پنج دقیقه کد نویسی است در خوش بینانه طرین حالت اگر صد نفر برنامه نویس علاقمند به این حوزه در ایران باشد.شما حدود 20-30 نفر را با خودتان همراه می کنید(به شرط داستن ایده جذاب)حالا برای این شرایط یک مدل ارایه بدین
  • ۰۴ تیر ۹۳ ، ۲۲:۴۴
  • عماد رضوانی
    • اگه واقعا بشه بصورت گسترده یک مدل رو پیاده سازی کرد که محشره.
    منظور از گسترده طیفه زیادی از مردم با دیدگاه های مختلف و کار بر روی یک ساختار. الان لینوکس چنین سیستمی داره.(حداقل من چنین تصوری دارم)
  • ۰۴ تیر ۹۳ ، ۲۲:۵۱
  • لونا
    • خوب آقا عماد نرم افزار ماهیت فیزیکی نیست که بتونه خودشو با دنیای اطرافش تطبیق بده و اینو کاملاً میدونی.
    نیاز به تطبیق بود یعنی مثلاً در مدل بخش بندی ایستا در سیستم عامل DOS ، اگر الان از همین رویکرد (مدل بخش بندی ایستا) استفاده می شد با توجه به توسعه سخت افزار و امکان استفاده بیشتر ، اصلاً منطقی نبود که فضای به اون خوبی (سخت افزار جدید) داشته باشیم ولی با مدل بخش بندی ایستا کار کنیم که تکه تکه شدن داخلی داره ، فرآیندهای فعال در آن تعدادشان در زمان بوت شدن هسته باید ثابت باشه.درسته که سادگی داشت ولی برای زمان خودش بود.چون که شرکت های سخت افزاری داشتند روی سیستم های جدیدتر با قابلیت های جدید کار می کردند.یک جورایی سیستم عامل وابسته به سخت افزار در حالیکه سخت افزار مستقل از سیستم عامل بود.یکی بزرگترین انقلاب ها در سیستم های محاسباتی و پردازش داده ، حافظه مجازی بود که خیلی ها برد کردند.اما هر چه نیاز به تطبیق با دنیای سخت افزار بیشتر می شد ، طیف توسعه بزرگتر می شد مثلاً ، ورود شبکه های کامپیوتری ، باعث شد که متخصصین این رشته در رابطه با هسته و توسعه آن نظر دهند و این باعث افزایش رقابت میان سیستم عامل ها و حتی سایر نرم افزار شد.کاملاً روشنه که مسائل محاسباتی هم دخیل بود ، مانند شی گرایی که برگ برنده هسته ها شد.
  • ۰۴ تیر ۹۳ ، ۲۳:۰۲
  • عماد رضوانی
    • بله. موافقم. ما موضوع پیاده سازی اون هست. نتیجه ای که من در طی طراحی این پروژه گرفتم این بود که سیستم عامل موضوعی جدا از سخت افزار هست. اما عجیب ماجرا اینجاست که اینها با هم در ارتباط هستند.  با تمام بزرگی یک سیستم عامل و الگوریتم های پیشرفته اون می بینیم که به سخت افزار وابسته هست. موضوع پورت شدن از یک مدل مثل x86 به arm هست. 
    حرف شما اینجا درسته و شکی نیست. اما فکر نمی کنید که ما حتی همین سخت افزار x86 رو کاملا نشناختیم؟!  موضوع من اینه که اول ما ببینیم این x86 و امسال اون چه قابلیت هایی دارن بعد بیان تصمیم بگیریم که چطور با این قابلیت ها بازی کنیم.
    اما معماری داخلی یک سیستم عامل موضوعی مجزاست. موضوع همون پورت شدن روی سخت افزار های دیگست. آیا مرزی باید بین این قضیه کشید؟ آیا مدل برای این موضوع حرفی داره؟
    مثلا الان من مشکلی با راه اندازی و یا نوشتن درایور شبکه برای یک سری از سخت افزارها ندارم( و این کار رو راه میندازه). اما موضوع اصلی معماری داخلی سیستم عامل هست که این جای بحث داره. دوباره برمیگردیم موضوع اول. معماری به سخت افزار وابسته هست؟! اگه هست پس پورت کردن چی؟ اگه نیست ارتباط داخلی چی؟
    به قول یکی سیستم عامل داخلی و خارجی داریم و باید از هم این دو رو مجزا کنیم.
  • ۰۴ تیر ۹۳ ، ۲۳:۰۴
  • m.j_banitaba
    • مشکل اول یک توسعه دهنده برای یک سیستم عامل به دلیل پیچیدگی سازمان آن زمان لازم برای بدست اوردن دید لازم جهت حرکت به سمت مناسب است . به نظر من اولین مرحله حل این مشکل است سریعترین روش برای آنکه یک نفر دانش آموز دبیرستانی به دید لازم جهت توسعه قسمتهای مختلف کد برسد.این مسیله می تواند جوابهای بلند مدت  مثل پنج ساله و جوابهای کوتاه مثل سه ماه را در بر داشته باشد که هرکدام مزایا و معایبی در بر دارد.ولی به نظر من چالش اصلی اینجاست . همانطور که در پستهای برنامه نویس هم دیده می شود اغلب دوست دارند واقعا سیستم عامل را بفهمند. یک راه حل سازماندهی شده می تواند برای یک دوره پنج ساله ما در نقطه شروع قرار دهد.
  • ۰۴ تیر ۹۳ ، ۲۳:۱۳
  • لونا
    • مسائل مدیریت پروژه مانند مسئله ریاضی نیست که راه حلش با جایگذاری یا روال های از پیش تعریف شده انجام شود.
    اول باید کل توسعه دهندگان پروژه روی مدل ها به توافق برسند یعنی نزدیک شدن نظرات به هم.سپس خروجی آن برای تصمیم گیری باید به تابع تعیین مدل داده شود ولی این تابع دو پارامتر دارد : پارامتر اول نتیجه توافق ، پارامتر دوم امکان سنجی پروژه است و خروجی یک مدل واقعی برای پروژه است که می توان از آن گراف زمانبندی تولید کرد.
  • ۰۴ تیر ۹۳ ، ۲۳:۲۰
  • عماد رضوانی
    • الان من متوجه نشدم. روی کدوم مدل ها؟
    امکان سنجی پروژه؟ پارامترها رو چی در نظر گرفتید؟
  • ۰۴ تیر ۹۳ ، ۲۳:۲۱
  • m.j_banitaba
    • دقیقا الان ما چقدر تصور صحیحی از جامعه برنامه نویسان داریم چندتا نظر سنجی علمی از طرف علوم انسانی بر روی ما ایرانیها صورت گرفته تا بر اساس واقعیتها مدل مناسب را تجربه کنیم یا نظریه پردازی کنیم. بدون آمار بدون دید چطور کار مدیریتی انجام میشه؟ آیا حتی متوانیم صرف اینکه یک دانشگاه صد مدرک مهندسی نرم افزار داده بگیم ما الان صدتا برنامه نویس داریم؟
  • ۰۴ تیر ۹۳ ، ۲۳:۳۸
  • لونا
    • پیچیدگی سازمان تمام نرم افزارها قابل حل است علت اینکه ما میگیم پیچیدگی اینه که ساختار سیستم عامل رو کاملاً نمیشناسیم مثلاً سیستم عامل کاملاً با معماری کامپیوتر رابطه 1 به 1 داره.و شناخت این رابطه است که به ما در حل مسائل الگوریتمی و ساختاردهی طراحی سیستم کمک می کنه و رمز موفقعیت گروه ها ، شرکت و غیره است.
  • ۰۴ تیر ۹۳ ، ۲۳:۴۱
  • عماد رضوانی
    • حرف من هم تغریبا به همین معنا هست. سیستم عامل با معماری کامپیوتر رابطه ۱ به ۱ داره. سیستم عامل قراره منابعی رو بشناسه و در اختیار کاربر قرار بده. ما هنوز با شناختن منابع مشکل داریم چه برسه لایه انتزاعی بین منابع و سیستم عامل قرار بدیم( یه چیزی تو مایه های VFS)
  • ۰۴ تیر ۹۳ ، ۲۳:۴۶
  • لونا
    • آقا عماد منظور مدل های توسعه نرم افزار است.
    امکان سنجی پروژه خارج از انتخاب مدل مناسب است و معمولاً قبل از تصمیم گیری برای انتخاب مدل انجام می شود اینکه مدل تا چه حد بتواند نیازهای پروژه را رفع کند بستگی به امکان سنجی درست دارد که خروجی آن ورودی برای برنامه ریزی پروژه است.
    پارامترها یعنی خروجی از دو تابع امکان سنجی و تصمیم گیری برای مدل:
    مثلاً:
    f(هزینه پروژه) = تخمین هزینه براساس معادله زمان و هزینه در نظر گرفته شده برای پروژه
    این تابع دارای دامنه هزینه است که می تواند با ثابت زمان محاسبه و هزینه بدست آید.گراف این تابع می تواند تجزیه و تحلیل شود و بهترین حالت را بدست آورد.
  • ۰۴ تیر ۹۳ ، ۲۳:۵۳
  • عماد رضوانی
    • فرض یک سال زمان با ۲۰ نفر پای ثابت چطور خروجی میتونه داشته باشه؟
    آیا همیشه هزینه ملاک هست؟ اگر هست هزینه زمانی؟ هزینه ریالی؟
    من ۲ دیدگاه  نسبت به این موضوع دارم. اولی اینکه باید تمام قوائد بازی و مدل سازی رو شناخت. و دوم اینکه تغییر معادله نسبت به وضع کنونی و جو کشور ما.
     اگر بخوایم ما برنامه نویسی برای کار بر روی پروژه انتخاب کنیم و دانشی هم از سیستم عامل نداشته باشه آیا به مشکل بر خورد نمی کنیم؟ موضوع اصلی من اینه که برنامه نویس های تیم نیازی به دانش تخصصی در مورد سیستم عامل لزوما نباید داشته باشند. داشتن انگیزه برای یک پروژه دانشجویی هم می تونه کارساز باشه.
  • ۰۵ تیر ۹۳ ، ۰۰:۱۷
  • لونا
    • اصلاً نمیشه با 20 نفر (فقط با گفتن) تخمین زد عماد جان ، چون که آیا هر 20 نفر توانایی نوشتن کد در سطح موردنظر را دارند؟آیا روی مدل توافق دارند؟ و ... آیا موازین اخلاقی IEEE را قبول دارند؟ (این سوال البته شاید مورد تایید همه صاحبنظران نباشد)
    هزینه مالی بستگی به پروژه داره.
    هزینه زمانی ، مدت زمان تحویل پروژه است که بازهم بستگی به پروژه داره برای پروژه شما ، هزینه زمانی باید براساس مدل توسعه تعیین گردد برای سایر پروژه ها مثل ساخت نرم افزارهای کاربردی ، در هزینه معیار مشتری هم دخیل است.

    اگر دانش نداشته باشی که اصلاً نمیشه.هیچ امکانی وجود نداره که بدون دانستن معماری کامپیوتر ، طراحی الگوریتم ، ساختارهای گسسته ، سازمان کامپیوتر ، شبکه ، سیستم عامل و ... بخوای طراحی انجام بدی اونم در حد هسته.
    مسئله اینجاست که چه دانشی مد نظر شماست.اگر من در مورد بوت ، صفحه بندی ،قطعه بندی و ... چیزی ندانم چگونه می توانم پیاده سازی در بهترین سطح همراه با معیار پیچیدگی الگورتیم پیاده سازی کنم.
    در مهندسی نرم افزار که خود از مهندسی سیستم نشات گرفته ، اگر شما اطلاعی از صورت مسئله نداشته باشی امکان حلش وجود نداره.برنامه نویسی اینجا مفهوم generic داره.
  • ۰۵ تیر ۹۳ ، ۰۰:۲۸
  • عماد رضوانی
    • دقیقا موضوع همینجاست. ۲۰ نفر بودیم و دانش تخصصی در مورد همه مباحثی که گفتی هم داشتیم که غمی نبود. مشکل اینجاست که خود من هم تسلط کامل بر تمام موضوعات گفته شده ندارم. موضوع پایه گذاری هست.
    من مشکلی با مدل سازی و تئوری قضیه ندارم و اون رو خیلی هم مهم میدونم. مشکل جایی دیگست. مشکل اینجاست که من نمی خوام تمام افراد از مدل و نوع پیشرفت پروژه اطلاعاتی داشته باشند. حرف شما درست که همه باید به توافق برسند. اما موضوع اینجاست که چند نفر واقعا می تونند وقت بزارند برای اینطور پروژه ها ؟! موضوع همون حرف آقای بنی طبا شد. ۱۰ دقیقه مطالعه و ۵ دقیقه برنامه نویسی.
  • ۰۵ تیر ۹۳ ، ۰۰:۴۱
  • لونا
    • منظور مدل سازی نیست مدل سازی مفهوم خارج از نقشه راه است.منظور من ایجاد نقشه راه است.شما اگر نقشه راه دقیق نداشته باشی صد در صد با مشکل مواجعه میشی.در کشور ما هم نقشه راه برای توسعه برنامه های آینده است مثلاً سند چشم اندازه 1404 ، که راهو داره نشون می ده.این نقشه گام به گام مراحل را به ما نشون می ده ریسک ها پیدا میشن ، نقاط ضعف و قوت شناسایی می شود روی رویکردها تصمیم گیری کلان می شود.برنامه ریزی ها دسته بندی می شوند:بلند مدت و کوتاه مدت.
    شما می خوای برای حل یک مسئله 10 دقیقه مطالعه کنی 5 دقیقه حل کنی؟
    این یک مسئله داخلی است که به برنامه نویس بر می گردد نه مدل توسعه ، خیلی سخته که شما به برنامه نویس دیکته کنی مراحل کارشو چطوری انجام بده ، اصلاً با شما کنار نمیاد.برنامه نویس فقط استانداردها را رعایت می کند.نه شیوه کد نویسی خود.
    شیوه کد نویسی یک مسئله شخصی است ، مانند اینکه شما به من بگین برای نوشتن روی کاغذ چطوری بنویسم.
    و این مسئله زیاد در این سالها خودش را درگیر مهندسی سیستم و نرم افزار نکرده.
    خوب سازمان های بزرگ علمی مثل آزمایشگاه پیشرانه جت JPL برای کد نویسی روی سیستم های رباتیک فضایی مثلاً طی یک برنامه آمد و استاندارد تعیین کرد.همه برنامه نویسان JPL باید از این استاندارد کدنویسی پیروی کنند.چرا ؟ چون که سیستم رباتیک فضایی یک سیستم کاملاً بحرانی بود و دائماً در حال تست.این یک مثال از استاندارد کدنویسی بود که گفتم
    پاسخ:
    جمع بندی تا بدین جای کار.
    نیاز به تهیه و تنظیم نقشه راه
  • ۰۵ تیر ۹۳ ، ۰۰:۵۲
  • عماد رضوانی
    • بسیار خوب. موارد لازم برای تهیه و تنظیم یک نقشه راه خوب و کارآمد؟
  • ۰۵ تیر ۹۳ ، ۰۸:۵۷
  • m.j_banitaba
    • اما نظر من کمی فرق داره . مشکل کشور ما نبود نقشه راه نیست.نبود همراهه (البته منظورم همراه اول نیست!!) شما با نقشه راه می خواهید دو جریان غیر هم جهت را هم جهت کنید تا توان سیستم را افزایش دهید. اما من می گم اول باید جریان ایجاد کنید.ما هنوز برق رو نمی شناسیم شما دنبال kvl , kcl می گردید . مگه لینوکس شریف و دها پروژه دیگه سیستم عامل در این مملکت با هزاران صفحه مستندات و پروپوزال و نقشه راه الان وضعیت عصف بار ندارند..........
    مرغ بی دل شرح هجران مختصر، مختصر کن.
  • ۰۵ تیر ۹۳ ، ۰۹:۳۲
  • عماد رضوانی
    • حالا من میگم عیبی نداره. نقشه راه داشتن هم خالی از لطف که نیست. موضوع برد برد هست. اول تا آخر یه نقشه راه باید موجود باشه. شاید یکی از بخش های همین نقشه راه طرح ریزی برای جمع کردن افراد پای ثابت یا ایجاد یک بستر برای توسعه شد.
    به نظرم بشینیم بحث کنیم که چطور میشه افراد روی جمع کرد هم بد نباشه. اینطور نیست؟
  • ۰۵ تیر ۹۳ ، ۱۰:۱۳
  • m.j_banitaba
    • من برای اینگونه پروژه ها روش مدیریتی هرمی را توصیه می کنم در این مدل شما یک طرح توجیهی انگیزشی میدید و هر نفر مسیول مدیریت حداقل دونفر در زیر مجموعه خودش میشه که با هم آشنایی دارند سپس هر نفر باید پروژه را به دو قسمت مساوی تقسیم کنه و هر نفر هر روز پنج دقیقه وقت جهت پیش برد کارد می گذارد. در نهایت شما یک نقشه هرمی از کل تقسیم بندی پروژه خواهید داشت.
  • ۰۵ تیر ۹۳ ، ۱۰:۲۶
  • عماد رضوانی
    • تقسیم بندی کار اینطور سخت نیست؟ با اینکه ایده خوبی هست و قابل گسترش هم هست اما مشکل تقسیم کار بوجود میاد. چون راس هر مینی هرم باید خودش مدیر باشه و این برای شروع یکم غیر معقول میاد. اینطور نیست؟
  • ۰۵ تیر ۹۳ ، ۱۲:۰۸
  • m.j_banitaba
    • مگه الان شما در چه سطحی دارین مدیریت می کنین که بقیه نمی کنن یعنی دوره های مدیریت دیدین و یا کتب مدیریتی مطالعه داشتین یا کسی رو در این سطح سراغ دارین که به عنوان مدیر پروژه بالای سر کار بذارین؟
  • ۰۵ تیر ۹۳ ، ۱۲:۱۶
  • عماد رضوانی
    • موضوع نوع مدیریت. خود مدیریت هست. تعریف یک کار برای یک گروه و ادغام نهایی کارها. موضوع همون آبجکت دادن با مجازی ساز برای توسعه.
  • ۰۵ تیر ۹۳ ، ۱۲:۲۴
  • m.j_banitaba
    • منظور من اینه که کاری هست که شما بتونین انجام بدین و بقیه نتونن؟ یا سوال بهتر چرا فکر می کنین بقیه نمی تونن مدیریت کنن؟؟ کسی که در سطح درایور نویسی سواد داره دو نفر آدم غیر خودشم می تونه مدیریت کنه.
  • ۰۵ تیر ۹۳ ، ۱۲:۲۹
  • عماد رضوانی
    • بابا موضوع این نیست. موضوع شکستن کارها در سیستم عامل هست. موضوع سیستم عامل داخلی و خارجی هست. تا یکی رابط درایور رو ننویسه میشه درایور نوشته بشه؟ گیریم نوشته بشه. پورت کردنش یه داستان دیگست.
    من منظورم اینه که بیاییم یه ترسیم از راه کنیم. بگیم اول کارها به این بخش ها شکسته بشه. بعد هر کار به یه مدیر. یه مدیر به چند مدیر دیگه و ...
    اما موضوع خود کار هست. نه اینکه  همه مدیر هستند یا نیستند.
  • ۰۵ تیر ۹۳ ، ۱۲:۴۵
  • m.j_banitaba
    • شکستن کارها وظیفه مدیریته. من اینجوری به مسیله نگاه می کنم.
  • ۰۵ تیر ۹۳ ، ۱۶:۱۰
  • m.j_banitaba
    • یه نکته :: در سیستم عامل تنها کار کردن برنامه نیست مورد نظر است . بلکه توسعه قابل فهم سریع کدها می باشد یعنی بعد از یک دوره توسعه به سرنوشت لینوکس دچار نشه .حالا نمی دونم نوع مستند سازی باید خاص باشه یا روش کد نویسی ؟؟
  • ۰۵ تیر ۹۳ ، ۱۸:۴۵
  • لونا
    • منظور شما از سرنوشت لینوکس چیه؟ مگه الان چه سرنوشتی داره؟
    پروژه ها دو دسته هستند:
    دسته اول: کسانی آنها را انجام می دهند که سالها درگیر پروژه های مختلف بودند ، تجربه کاری بالایی دارند ، حداقل در تیم آنها ، افراد روی پروژه های مرتبط با ریاضیات کار کردند ، و در نسخه های اولیه مستند سازی هم نمی کنند ، اما بعدها وقتی محصول وارد خانه های مردم شد ، حالا دنبال مستند سازی و تحلیل پروژه در سطح بالا هستند چون که نیاز پروژه را برای تطبیق با تکنولوژی می بینند ، و نیاز به مدل دارند.حالا مسئله توسعه دهنده شخص سوم هم این وسط است ، و برنامه ریزی باید دقیق و شمرده برداشته شود.
    دسته دوم: کسانی که متدلوژی را انتخاب می کنند ، طبق متدلوژی ، مراحل فرآیند را پیش روند ، تحلیل ، مستند سازی ، مهندسی خواسته ها ، آزمون ، اعتبارسنجی ، و ... انجام می دهند البته از همان ابتدا.

    به طور کلی برنامه ریزی برای پروژه های نرم افزاری ، قبلاً بسیار سخت بود ، چون که تحلیل فقط برای رشته های مهندسی سیستم بود ، اما دانشمندان بسیاری با تحقیقات متوجه شدند که سیستم نرم افزاری با ماهیت غیر فیزیکی ، هم یک سیستم خوانده می شود و نیاز به مهندسی دارد و مهندسی برابر با تجزیه و تحلیل ، انتخاب متدلوژی و حرکت صحیح و شمرده ، در جهت رسیدن به اهداف پروژه.
    من از شما سوال دارم ، شما چگونه توسعه و اعتبار سنجی نرم افزار را بدون اینها انجام می دید؟
  • ۰۵ تیر ۹۳ ، ۱۹:۰۲
  • لونا
    • ضمناً بله کارهایی است که خیلی نمی تونن انجام بدن ، شما چه احتمالی می تونه بدی که چیزی که شما بلدی من هم بلد باشم؟ پس اگه اینجوری بود نه ویندوز ، و نه سیستم عامل هایی دیگه نیاز به یک تیم حرفه ای داشت ، یک نفر می نشست و کد می زد ، با کسی هم کاری نداشت.
    مسئله ما اینه که فکر می کنیم اگر زبان C یا C++ بلدیم دیگه کار تمومه ، اما همین دیشب هم بحث درباره پیچیدگی سازمان کامپیوتر کردیم و خود شما گفتی که پیچیدگی داره.
    نیاز به شناخت تمام مولفه های کامپیوتر (زیر سیستم) و نوشتن یک سیستمی که بتونه تمام زیر سیستم را مدیریت کنه ، نیاز به تیم ، برنامه ریزی دقیق داره چون قرار توسعه پیدا کنه ، اعتبارسنجی بشه.
    همین مسئله شناخت باگ ها ، و حفره ها ، در هر سطوحی از ساخت و تولید نیازمند برنامه ریزی دقیق در طول فرآیند طراحی پروژه است. نه در انتها که نرم افزار را داخل یک کامپایلر باز کنیم میان میلیون ها خط کد دنبال باگ ، یا حفره بگردیم این روش کاملاً قدیمی است.
  • ۰۵ تیر ۹۳ ، ۱۹:۵۴
  • عماد رضوانی
    • من با نظر آقای بنی طبا در مورد توسعه لینوکس کاملا مخالفم. لینوکس نمونه قدرت توسعه باز هست. اینو دیگه همه می دونند.
    دوم اینکه یک بار بشینیم یه طرح اولیه بدیم. انتزاعی به موضوع نگاه کنیم و حداقل مثل شکل آدم بشینیم اونو طرح کنیم. بعد بیایم اونو رنگ کنیم و چشم و گوش واسش طراحی کنیم. منظورمو گرفتین؟
    یه شکل اولیه. یعنی یه نیاز سنجی گرافیکی بصورت مختصر. نظر؟
  • ۰۵ تیر ۹۳ ، ۲۱:۰۸
  • لونا
    • در ادامه مطالبم روش یافتن باگ ها ، و اعتبار سنجی کد به طور مستقیم دقیقاً به قبل از توسعه شی گرایی بر می گرده ، و روش کاملاً قدیمی است.بله اون زمان که یونیکس هم نوشتند خبری از تجزیه و تحلیل و مهندسی نرم افزار به این صورت امروزی نبود. اما بعدها گروهای مختلفی متوجه شدند که با این راه نمیشه جلو رفت ، و باید روش های جدید جایگزین روش های قدیمی بشه. این در هر زمینه ای از خدمات گرفته تا صنعت اتفاق می افته.

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

    چه نوع نیازسنجی گرافیکی مد نظر شماست؟
    مگه شما متدلوژی را انتخاب کردید؟
  • ۰۵ تیر ۹۳ ، ۲۱:۱۴
  • عماد رضوانی
    • با همه موضوعات موافقم.
    مستند سازی واقعا وقت گیر هست اما نبودش هم فاجعه ...
    نیازسنجی گرافیکی یعنی لزوم ایجاد یک سیستم عامل و یا موارد مورد نیاز برای طراحی یک سیستم عامل.
    متدولوژی زمانی به کار میاد که پروژه سیستم عامل مفهومی مشخص برای همه ما پیدا کرده باشه و بعد بیایم اجزا تعریف و نیازسنجی کنیم و بعد متدولوژی برای اجرای اون انتخاب کنیم. البته تئوری خودم بود. اگه اشتباه میکنم بگید.
  • ۰۵ تیر ۹۳ ، ۲۱:۴۰
  • لونا
    • خوب مستند سازی انجام نده ، با متدلوژی هایی مثل Agile لازم نیست مستند سازی انجام بدی و فقط پیاده سازی مهم است.و این سرعت کار را بالا می برد.اما مهم ترین مسئله در این زمینه مدیریت مهندسی خواسته ها است که باید کاملاً تحلیل ، و برنامه ریزی دقیق برایش انجام بشه.
    مهندسی خواسته ها: یعنی نیازسنجی دقیق پروژه و برنامه ریزی برای تغییر خواسته ها ، مدیریت خواسته های جدید و ... است.
    اون چیزی که شما می گی اسمش معماری سیستم عامل است است که باید برای طراحی سیستم عامل ، یکسری از استانداردها را رعایت کنی و به پروژه اعمال کنی.حالا این معماری چیست؟
    خوب اصلاً کاری به مهندسی نرم افزار برای سیستم نداریم.
    خوب باید ساختار هسته ها را بشناسی و درک کنی ، خوشبختانه ، تمامی هسته ها از Exokernel دانشگاه MIT گرفته تا هسته پیوندی ، ریز هسته ، هسته یکپارچه و ... همگی دسته شما را باز گذاشتند تا بتونی ماژول هایی را به آن ها اضافه کنی.اما اینو بدان که کاملاً حواست باید برای اضافه کردن یا تغییر ساختار هسته جمع کنی چون که همین هسته حکم اصلی سیستم عامل داره و هرچی اتفاق بیافته اینجا اتفاق میافته. اگر بیشتر خواستی ، بیشتر توضیح میدم.

    ضمناً درباره SDK باید بیای بالای هسته یک framework بنویسی که خود شامل کتابخانه ای شامل توابع اصلی برای دسترسی به زیر سیستم ها (ماژول های درون هسته مانند مدیریت حافظه ، مدیریت دستگاهای ورودی/خروجی) است.
    این توابع کتابخانه ای به برنامه نویس شخص سوم اجازه می دهد که از هسته به عنوان پلتفرم برای توسعه برنامه های سیستمی و کاربردی استفاده کند مثلاً برنامه نویس میاد یک IDE در بالای هسته می نویسه که امکان نوشتن برنامه های کاربردی رو به سیستم عامل شما میده.
    اگر خواستی بیشتر توضیح می دم.
  • ۰۵ تیر ۹۳ ، ۲۲:۰۶
  • عماد رضوانی
    • بله. تغریبا با ساختار هسته ها و قابلیت ها و معایب و مزایای  اونها تقریبا آشنایی دارم.
    پس ۱. موضوع نوع هسته نیست.
    در مورد SDK فعلا زوده نظر قطعی بدیم.
    پس ۲. SDK باید بعد از تعریف دقیق از معماری و نوع سیستم عامل مشخصی بشه.

    در نهایت حرف من اینه که یک بار بیایم سیستم عامل رو چالش کنیم و بخش های اونو در بیاریم و بعد هر کدوم رو نظر بدیم و نهایتا چیزی به نام پروژه سیستم عامل تعریف کنیم.
    اما اگه توضیحاتت رو مستند کنی خیلی بهتره. بازم ممنون.
  • ۰۵ تیر ۹۳ ، ۲۳:۲۳
  • لونا
    • موارد زیر را باید به چالش کشیده شود:

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

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

    1- شناخت ثبات ها ، گذرگاه ها ، مدخل ها و ...: عملیات پاک سازی ، انتقال داده ، فعال کردن ، ...
    2 - سازمان کامپیوتر (معماری کامپیوتر) : کار با ریز عمل ها و ...(مانند عملیات انشعاب ، جمع ، تفریق و ...)
    3- روال ها : کار با پشته فراخوانی (برای عملیات ارسال پارامتر به توابع ، بازگشت مقادیر) و ...
    4- مدیریت وقفه ها: تعیین یک ساختاری برای مدیریت وقفه از طریق روال های گرداننده وقفه ، مانند فراخوانی وقفه و ...

    خوب این سطح (شماره 1 و 2 و 3) ، سطح سخت افزار است که در ویندوز توسط لایه HAL مدیریت می شود.

    5 - مدیریت فرآیند: شامل ایجاد فرآیند ، حذف ، تغییر حالت فرآیند ، علامت دادن در زمینه سمافورها (هم زمانی) و ...
    6 - حافظه ثانویه: کار با بلوک های داده ، مانند عملیات خواندن و نوشتن ، تخصیص بر روی بلوک ها و ...
    7 - حافظه مجازی: کار با قطعه بندی و صفحه بندی. مانند خواندن ، نوشتن و ...

    خوب این سطح (شماره 5,6,7) ، سطح مدیریت حافظه است.

    8- ارتباطات بین فرآیند و نخ: مانند استفاده از pipe برای ایجاد ، حذف ، خواندن و نوشتن بین دو فرآیند.
    9 - سیستم مدیریت پرونده
    10- مدیریت دستگاه های ورودی و خروجی: کار با دستگاه ها با استفاده از فراخوان های سیستمی مانند خواندن و نوشتن در دستگاه و ...
    11 - SDK برای کاربر: جهت مدیریت فرآیندهای کاربران
    پاسخ:
    چالش ها
  • ۰۵ تیر ۹۳ ، ۲۳:۴۶
  • عماد رضوانی
    • بله. لایه ها از دید شما:
    لایه HAL که مشخصه و باید ما یک پلتفورم برای شروع انتخاب کنیم.(البته برای شروع و باید آینده نگری هم داشته باشیم مثل arm)
    لایه دوم شما که به عنوان سطح مدیریت حافظه معرفی کردید به شرح زیر میشه دسته بندی کرد:
    ۱. مدیریت فرآیند
    ۲. سرویس مدیریت حافظه
    اما در لایه سوم شبهاتی وجود داره:
    ۱. ارتباط بین فرآیند ها در بخش قبل باید باشه(باز باید اینجا معماری هسته هم دخیل کنیم و نظر بدیم. اما اینطور به نظر میاد)
    ۲. سرویس حافظه ثانوی در اینجاست(بازم هسته دخیل هست)
    ۳. و ...

    یه تعریف از سیستم عامل بیان می کنید.
  • ۰۶ تیر ۹۳ ، ۰۰:۰۰
  • لونا
    • این لایه ها از دید من نیست از تحقیقات دید دانشگاه MIT است.
    لایه HAL کاملاً بخش بالایی را مدیریت می کند مثلاً دریافت دستورات به زبان C و تبدیل به زبان اسمبلی را بر عهده دارد.
    درون مدیریت حافظه فرآیندها زندگی می کنند محل زندگی آنها آنجاست و حافظه به عنوان یک صف زمانبند کوتاه مدت آنجا است که توزیع کننده بعد از زمانبندی از آنجا شروع به انتقال کلمات موردنظر (دستورالعمل ، ثبات وضعیت پردازنده و ...) به پردازنده می کند.
    در لایه مورد نظر شما ارتباطات بین فرآیند چون در سطح بالاتری (از لحاظ زبان برنامه نویسی) کار می کند است.چون که مثلاً پیاده سازی مکانیزم هایی مانند خوانندگان و نویسندگان ، تولید کننده و مصرف کننده نیازمند کد نویسی در سطح بالاتری نسبت به سطوح پایین تر است.اگر در سطوح پایین تر قرار دهید منجر به کار بسیار زیاد می شود و از لحاظ منطقی اصلاً درست نیست.
    منظور شما از اینکه هسته دخیل است چیست؟ یعنی منظور شما این است که هسته جداگانه است؟
    کل این لایه ها یک نمای کلی از هسته است.

    تعریف سیستم عامل: سیستم عامل برنامه ای است که اجرای برنامه های کاربردی را کنترل و به صورت واسطی بین کاربر و سخت افزار عمل می کند. و این به معنای هسته نیز است.
    و امکان سهولت استفاده از کامپیوتر ، و باعث کارآمد تر شدن استفاده از منابع کامپیوتر می شود.
  • ۰۶ تیر ۹۳ ، ۰۰:۰۸
  • عماد رضوانی
    • خوب چون دید MIT هست که منبع نمیشه. لینوکس/ویندوز و یا همین minix که منبع آموزشی هم هست کاملا با این ساختار متفاوتند.
    ۲ دیدگاه از نظر طراحی سیستم عامل از نظر من مطرح هست. یکی معماری سیستم عامل که همین بحث شماست و یکی معماری هسته سیستم عامل که توضیحات منه. شاید دید شما برای انتزاعی قرار دادن موضوع درست باشه. اما در پیاده سازی هسته ممکن هست تغییر کنه.

    با توجه به تعریف سیستم عامل یک شکل خوب به همراه توضیحاتمون ایجاد کنیم. زمانی که جمع بندی و تکمیل کردیم به اون بخشش اضافه می کنیم. منظورم طراحی mind هست:
  • ۰۶ تیر ۹۳ ، ۰۰:۱۴
  • لونا
    • یعنی منظورت اینه که MIT منبع دقیقی نیست.
    اگر نیست پس من از همین الان به همه اعلام می کنم که ریز هسته یک چیز مذخرف است.
    در مقالات تحقیقاتی تمام سیستم عامل هایی که شما اشاره کردید به منابعی از این دانشگاه اشاره شده است.
    و تمام دانشگاه های دیگر دنیا.

    خوب حالا میشه بگید هسته از دید شما چیست؟
    اون چیزی که شما به عنوان یک تصویر در اینترنت از سایت های مثل ویکی پدیا و ... می بینید یک تصویر کلی از هسته را ارائه می دهد در حالیکه ساختاری که من گفتم فقط جزئیات ابتدایی از هر بخش هسته بود.
  • ۰۶ تیر ۹۳ ، ۰۰:۲۴
  • عماد رضوانی
    • نه اینکه MIT منبع دقیق نباشه. منظور از منبع در مورد ساختار هسته هست. هر هسته ای امکان داره ساختار خودش رو داشته باشه. مدلی که شما گفتید تقریبا شبیه به ساختار هسته بود.
    به نظر من یکی از میکرو کرنل هایی که خوب پیاده سازی شده اند minix هست و این هم شکی در اون نیست که اگه بود دانشگاه برکلی تا الان اون رو رد کرده بود.
    هسته از دید من و شما نداره. قلب یک سیستم عامل هسته هست. تصویر کلی دقیقا منظور من هست. اینکه بیایم بگیم یه هسته داریم مثلا با معماری میکرو و چند لایه بصورت .... و دو سطح هسته و کاربر و .... . و بگیم در کلام لایه قرار هست مدیر فرایند ها باشه با چه سطحی و بگیم کجا مدیر حافظه باشه با چه سطحی تا آخر.
    موضوع رو دوباره میگم. انتزاعی به موضوع نگاه کنیم برای شروع بهتره. مهم نیست زمان بندی با چه الگوریتمی داره کار میکنه. مهم اینه که یه چیزی با این وظیفه تعریف شده هست. مهم نیست مدیر حافظه الگوریتمش چیه. مهم اینه که داره کار میکه. حالا بعدا مفصلا در مورد هر کدوم سر فرصت بحث می کنیم.
  • ۰۶ تیر ۹۳ ، ۰۰:۳۱
  • لونا
    • هر کدام از این موردهایی که من داخل اون ساختار گفتم ، دقیقاً مربوط به همین مسائل است و اگر بخواهید وارد جزئیات هر کدام بشید در حد یک ترم دانشگاه یا شاید بیشتر نیاز به تحقیق و پژوهش حرفه ای داره.
    اتفاقاً مهم است که زمانبندی با چه الگوریتمی کار می کند تمام این الگوریتم ها نیاز به شبیه سازی روی نرم افزارهای خاص داره تا با استفاده از نتایج شبیه سازی بتوان در مورد سیاست های سیستم عامل در قبال برنامه ریزی برای فرآیندها تصمیم گیری کرد.اگر اصلاً در نظر گرفته نشود صد در صد با مشکل بر خواهید خورد.
    شناخت الگوریتم های حافظه هم مهم است اتفاق بحرانی تز از برنامه ریزی برای زمانبندی است.
    اینکه هر هسته ساختار خودش را داره بنده انکار نمی کنم.انتخاب ساختار بستگی به هدف طراحی سیستم عامل داره نمی تونیم بیام بگیم خوب ما ریز هسته را انتخاب می کنیم چون بهینه تر از بقیه است برای هر موضوع انتخاب باید دلایل علمی و منطقی در نظر گرفت.
  • ۰۶ تیر ۹۳ ، ۰۰:۳۵
  • لونا
    • در ادامه مطالب قبلیم مثلاً در مورد رویکردهای مقابله با بن بست در تخصیص و درخواست منابع به فرآیندها ، سه سیاست مطرح است: پیش گیری ، اجتناب ، کشف.که هر کدام شامل طرح های مختلفی هستند چگونه می خواهید این الگوریتم ها را در نظر نگرید در حالیکه هر کدام برای خود مزایا و معایب دارد.چون انتخاب هر طرح ورودی برای سیاست های سیستم عامل محسوب میشه.
  • ۰۶ تیر ۹۳ ، ۰۰:۳۶
  • عماد رضوانی
    • بله بله بله. شکی نیست در مورد حرف شما. اما منظور بنده این نیست. آقا زمانبندی  یعنی چی ؟! خود زمانبندی حرف من هست. یعنی یک از اجزای سیستم عامل. اینجا مهم نیست که الگوریتم چی انتخاب میشه. اینجا اجزا مهم هست.
    مثلا در حافظه ما صفحه بندی و حافظه مجازی داریم. اما چه الگوریتمی برای بلوک خالی پبدا کنیم میشه مرحله بعد.
    کلا بحث معرفی اجزا سیستم عامل هست.
  • ۰۶ تیر ۹۳ ، ۰۰:۴۶
  • لونا
    • خوب شما به عنوان مدیر تیم پروژه موضوعات به عنوان اجزای سیستم عامل دسته بندی کن اینجا بگو تا بحث کنیم.
  • ۰۶ تیر ۹۳ ، ۰۰:۵۸
  • عماد رضوانی
    • ساده ترین نگاه:
    ۱. ورودی/خروجی
    ۲. پردازشی
    ۳. ذخیره و بازیابی
    حالا هرکدوم زیر مجموعه دارن. به نظر من همون mind تهیه کنیم بهتره.
  • ۰۶ تیر ۹۳ ، ۰۱:۱۹
  • لونا
    • پردازش یعنی چی؟ منظورم اینه که چه جیزی رو شامل میشه؟
    ذخیره بازیابی مربوط به چه جیزی است؟
  • ۰۶ تیر ۹۳ ، ۰۹:۱۱
  • عماد رضوانی
    • این طرح اجزای سازنده سیستم بود.
    پردازش یعنی مدیر فرآیند و مدیر حافظه
    ذخیره و بازیابی هم که حافظه های ثانویه
  • ۰۶ تیر ۹۳ ، ۱۰:۳۴
  • لونا
    • اما...

    خوب من با حافظه مجازی شروع می کنم.
    نگاهی به سیستم عامل ویندوز می اندازیم.
    تخصیص حافظه و انجام صفحه بندی در سیستم عامل ویندوز توسط مدیر حافظه مجازی انجام می شود.و به صورتی طراحی شده است که با سازگاری کاملی با معماری هایی متنوعی از جمله معماری اینتل و ADM64 ، و معماری Itanium داشته باشد.از این رو سیستم ویندوز از صفحه های 4 تا 64 کیلوبایتی استفاده می کند.
    مسئله ترجمه آدرس مجازی در هر سیستمی مهم است در سیستم ویندوز فرآیندهای 32 بیتی (برای سیستم های 32 بیتی) از فضای آدرس 32 بیتی به طور مستقل استفاده می کنند که امکان تخصیص تا 4 گیگابایت را دارد.همانطور که در بخش مربوط به فرآیندها در این سایت گفتم ، فرآیند در ویندوز به صورت فرآیند کاربر است که در آن به هسته اجازه اجرا می دهد این موجب می شود که سربار سیستم از لحاظ سوییچ کردن های زیاد به طور قابل ملاحظه ای کاهش یابد.از این رو قسمتی از حافظه برای سیستم عامل ذر نظر گرفته شده است. به طور کلی ویندوز به هر برنامه کاربردی 2 گیگابایت فضای آدرس مجازی می دهد و تمام فرآیندها در این دو گیگابایت به صورت اشتراکی استفاده می کنند.خوب همانطور که ما می دانیم ویندوز از مدل هسته پیوندی (Hybrid) استفاده می کند که موجب اجرای بعضی از سرویس های سیستم عامل در سطح هسته می شود.از این جهت که بعضی سرویس ها مثل ارتباطات فرآیندها در ریز هسته در خارج از هسته به عنوان یک سرور در نظر گرفته می شوند در مدل پیوندی کمی متفاوت است.به همین جهت ارائه راهکارهایی برای مدیریت سرورها برای حافظه مهم است.فضای آدرس به صورت پیش فرض در ویندوز به چهار بخش تقسیم شده است که بعداً خواهم گفت.
  • ۰۶ تیر ۹۳ ، ۱۰:۴۳
  • لونا
    • Denning و همکارانش در مورد چندبرنامگی رویکردی را مطرح و پیشنهاد کردند.
    نام این معیار L = S است و به گونه ای سطح چندبرنامگی را پیکربندی می کند که متوسط زمان بین خطاها برابر متوسط زمان لازم برای پردازش یک خطای صفحه شود.بعد از مطالعات نشان داده شد که در این مکان استفاده از پردازنده به حداکثر می رسد.
    به طور کلی با رویکرد حافظه مجازی ، انتظار می رود سطح چند برنامگی افزایش یابد یعنی مشغول نگه داشتن CPU برای بالابردن کارایی که به نظر بنده رابطه مستقیمی با زمان پاسخ دارد.چون که با افزایش تعداد خطاهای صفحه استفاده از پردازنده برای پردازش کلمه مورد نظر کاهش می یابد.
    نظر شما چیست؟
  • ۰۶ تیر ۹۳ ، ۱۱:۰۲
  • لونا
    • بررسی سیستم رفاقتی در مدیریت حافظه
    ایجاد یک تعادل در بخش بندی ها و کاهش سربار خیلی مهم است.در بخش بندی پویا ، تکه تکه شدن داخلی نداریم ولی متاسفانه تکه تکه شدن خارجی داریم که حافظه را کارآمد نمی کند.یک راه حل این بود که ما عملیات فشرده سازی را انجام بدیم.خوب سربار زیادی داشت . چون که هر پروسه فشرده سازی باعث می شد که آدرس صفحات عوض شود و این یعنی تغییر آدرس فرآیند.حالا شما حساب کنید که چندبار این انجام شود شما باید چندین بار به آدرس های مختلف مراجعه کنید.الگوریتم هایی هم ارائه شد مانند بهترین برازش و ... ، اما در تخصیص بلوک های آزاد به صفحات ناکارآمد بود.البته اگر این الگوریتم ها در کنار فشرده سازی انجام می شد آن هم با بسامد پایین تر شاید باعث بهتر شدن الگوریتم می شد.
    سیستم رفاقتی باعث حل این مسائل شد.
    حافظه در این طرح حافظه مانند الگوریتم دودویی ، به دو قسمت تقسیم و شبیه به مدل حریصانه حافظه را تخصیص می دهد که باعث بهینه شدن می شود.
    اگر خواستید بیشتر توضیح می دهم.
    پاسخ:
  • ۰۶ تیر ۹۳ ، ۱۱:۴۸
  • لونا
    • اندازه صفحه مسئله بسیار مهمی در مشخص کردن مدل صفحه بندی است.اندازه صفحه ، تاثیر مهمی بر تکه تکه شدن داخلی دارد ، اینکه مایل باشیم اندازه صفحات را به یک حدی مثلاً مقدار n کوچک در نظر بگیریم ، تاثیر مهمی بر کاهش تکه تکه شدن داخلی دارد.امابه نظر شما کوچک کردن صفحات برای یک فرآیند مطلوب است.تحقیقات بسیاری نشان داده که با کوچک تر کردن صفحات ، تعداد صفحات بیشتر می شود و این باعث افزایش جداول صفحه به طور کلی بزرگ شدن می شود.مسئله حافظه مجازی ، باید این جدول را به دوش بکشد.از طرفی اندازه بزرگ برای صفحات نیز باعث حافظه مجازی بیشتر می شود پس دوستان باید در نظر داشته باشید که چه حدی باید برای اندازه صفحه مد نظر باشد.معیار مراجعات محلی نیز باید برآورده شود.باید بتوان نرخ خطای صفحه را کاهش داد.اما چگونه؟
    چگونه می توان با در نظر گرفتن اندازه صفحات و حافظه مجازی بهترین الگوریتم و بهینه ترین را انتخاب کرد؟
    آیا ترکیب صفحه بندی و قطعه بندی می تواند روی این موضوع تاثیری داشته باشد.
    مسائلی مانند حافظه پنهان چقدر در طراحی جایگزینی صفحات می توانند نقش خوبی ایفا کنند.
  • ۰۶ تیر ۹۳ ، ۱۳:۲۵
  • لونا
    • رشد فرآیند
    در طول عمر فرآیند احتمال رشد آن بالاست یعنی تغییر نیاز به تغییر فضای آدرس مجازی.کاری که مایکروسافت انجام داد این است که روی مدیریت رشد فرآیند نیز برنامه ریزی کرد و با آگاهی از رشد فرآیند در طول عمر آن سیاست هایی در نظر گرفته شد.
    تعیین اندازه ثابت برای فضای مجازی به این معنا نیست که رشد فرآیند در نظر گرفته نشود ، چون به هر حال ما بحث تعلیق بخش های فرآیند هم داریم به این صورت که اگر به آن قسمت از برنامه نیاز است ، صفحات آن بارگذاری شود البته با توجه به مجموعه کاری ، چون در هر حالت احتمال افزایش مجموعه کاری به صورت نمایی وجود دارد.
    خوب با توجه به معماری 32 یا 64 می توان تصمیمات جداگانه ای اتخاذ کرد.
    تغییر در اندازه نیازمند تخصیص پویا است که باید دقت کافی انجام شود زیرا مسائل ترجمه آدرسها ، نباید سرباری برای سیستم عامل داشته باشد مثلاً یک رویکرد این است که آدرس هایی که قبلاً ترجمه شده است دیگر ترجمه نشود.
  • ۰۶ تیر ۹۳ ، ۱۳:۳۳
  • عماد رضوانی
    • نیاز هست که تخصیص حافظه پویا توسط هسته انجام بشه؟ کار درستی هست؟ تئوری های جدیدی که من داشتم مطالعه می کردم این بود که بهتره چیزی به نام malloc و امثال اون ربطی به هسته نداشته باشه.
    دوم اینکه مبنای حافظه مجازی در لینوکس و ویندوز paging هست. درسته؟ اگه پردازنده ای این قابلیت رو نداشته باشه چی اتفاقی می افته؟
  • ۰۶ تیر ۹۳ ، ۱۳:۵۳
  • لونا
    • پردازنده ها برای قابلیت صفحه بندی و قاب بندی کاملاً مستقل هستند چون که این دو مورد یک استانداردی برای حافظه است و پردازنده فقط وظیفه خواندن کلمه از حافظه را دارد که کاملاً میدونید.
    صفحه بندی و قاب بندی مکانیزم جا دادن کامل فرآیند در داخل حافظه است.و یک سخت افزار به نام MMU وجود دارد که وظیفه ترجمه آدرس ها را برای پردازنده بر عهده دارد.از این رو حافظه معمولاً محدود است و باید بهینه استفاده شود.ما همه دوست داریم کل برنامه داخل حافظه بارگذاری شود ، در حالیکه این امکان با توجه به محدودیت سخت افزار حافظه امکان پذیر نیست.لذا برای قدرت دادن به این مفاهیم مسئله مجموعه کاری توسط آقای Denning مطرح شد که تاثیر مهمی بر مدیریت حافظه مجازی داشت.
    البته از وقتی موضوع چند نخی پیش آمد ، یک برگ برنده برای طراحان محسوب شد چون که واحد کاری کوچک بهتر عمل می کند تا خود فرآیند بزرگ.
    مدیر حافظه در سیستم عامل هایی مانند ویندوز خارج از هسته است من قبلاً هم گفتم که شما دستت برای دستکاری داخل هسته باز است.اگر داخل هسته انجام بشه کمی مایل به روش های قدیمی داره.البته حافظه مجازی داخل هسته انجام میشه چون که یک بخش کاملاً مجزا و مدیریت مجزایی داره.
    مسئله برنامه نویسی نیست ، چون که مدل نیاز به تحلیل و تصمیم گیری داره.
  • ۰۶ تیر ۹۳ ، ۲۰:۵۳
  • لونا
    • رویکرد نخ ها در سیستم عامل و تفکیک نخ ها
    با توجه به اینکه مسئله سرعت اجرا و کاهش سربار جزء مسائل مهم در محاسبات سیستم است ، نیاز به این دو مولفه باعث شفاف سازی ، و مرتب بودن کارها در یک سیستم عامل شد.
    نخ ها در اداره کردن هم زمانی نسبت به فرآیندها بسیار خوب عمل می کنند و همچنین می توانند در عملیات های ناهمگام (نه براساس زمان سیستم) استفاده شوند که خوب موجب هماهنگی بیشتر در عملیات های ورودی و خروجی می شود.
    با ورود رویکردهایی مانند شی گرائی ، ماژولار شدن برنامه ها نیز افزایش پیدا کرد و نخ ها توانستند به عنوان گلوگاه های این رویکردها مطرح شوند.
    دسته بندی پردازش ها نیز نقش مهمی در خلق نخ ها داشت امروز تقریباً برنامه های مطرح در سیستم من و شما ، شبکه ای از نخ های مرتبط به هم و مستقل از هم را در جهت افزایش سرعت و کارایی دارند.
    وجود فضای آدرس مشترک نیز باعث افزایش قابلیت همکاری میان نخ ها شده است و گاهاً بدون دخالت هسته این کار انجام می شود.
    ساختار چند نخی بگونه ای است که امکان حریم خصوصی برای جلوگیری از دخالت سایر نخ ها در یک فرآیند ، و از تخریب جلوگیری می کند.
    لازم به ذکر است که در رویکرد چندنخی ، می توان یک مدل مانند مدل چرخه حیات فرآیند ، برای آن ساخت.که البته بعضی از رفتارها در آن وجود ندارد که این خود ایمنی را برای نخ های یک فرآیند و خود فرآیند به همراه دارد.به عنوان نمونه در مدل نخ ، با توجه به مزایای حافظه مجازی ، امکان تعلیق برای نخ در نظر گرفته نشده چون که این موضوع در سطح فرآیند است و این باعث می شود که تمام نخ ها نیز به بیرون مبادله شوند.
    در بسیاری از سیستم عامل ها مانند ویندوز ، بین نخ ها تمایز قائل شده است یعنی نخ ها به دو دسته نخ های سطح کاربر و نخ های سطح هسته تفکیک شده اند.
    نخ های سطح کاربر به طور کامل توسط خود کاربر مدیریت می شود.وجود چارچوب های پیشرفته در سیستم عامل ها باعث شده است که کتابخانه هایی برای این مسائل منظور شود.از این رو ویندوز سیستم عامل را به دو بخش فضای کاربر و فضای هسته تقسیم کرده است که نخ های سطح کاربر در فضای کاربر اجرا می شوند.و تمام پروسه ساخت ساختمان داده های نخ توسط چارچوبی که در فضای کاربر قرار دارد انجام می شود.در نخ های سطح کاربر هسته هیچ دخالتی ندارد پس نباید انتظار گرفتن خدمات از هسته بود ، خدماتی مانند اجرای روی چندین پردازنده.اما نخ ها سطح کاربر دارای امتیاز کاهش سوییچ کردن بین فرآیندها و نخ ها هستند.با این وجود سوییچ بین نخ ها و زمانبندی نخ کاملاً توسط کاربر انجام می شود و در فضای کاربر است.اما مسئله ای مانند مسدود بودن باعث کاهش کارایی نیز می شود زیرا با مسدود بودن یک نخ کل نخ های فرآیند نیز مسدود می شود.البته نخ ها در حالت اجرا هستند ولی نه بر روی پردازنده بلکه از دید چارچوب در فضای کاربر ، زیرا تغییر رفتار نخ تنها توسط چارچوب امکان پذیر است و هسته دخالتی ندارد.
    در بحث بعدی در مورد نخ های سطح هسته خواهم گفت...
    پاسخ:
    رویکرد نخ ها در سیستم عامل و تفکیک نخ ها
  • ۰۶ تیر ۹۳ ، ۲۱:۰۸
  • عماد رضوانی
    • صرف نظر از سطح اجرایی نخ ها:
    چند چالش در مورد نخ ها رو بررسی کنیم:
    ۱. وجود ساختمان داده های استراکی بین نخ ها.
    ۲. گزارش خطا و وضعیت یک نخ.
    ۳. چند نخی بودن فرایند پدر و تاثیر آن بر فرایند فرزند.
    برای شروع کافیه فکر کنم.
  • ۰۶ تیر ۹۳ ، ۲۱:۴۱
  • لونا
    • 1 - ساختمان داده های نخ ها اشتراکی نیست و فقط در فضای آدرس کاربر و بلوک کنترل فرآیند PCB اشتراکی کار می کنند که اینها یعنی ساختمان داده فرآیند.
    موارد غیر اشتراکی:
    نخ ها برای هر کدام به طور مستقل یک بلوک کنترل نخ TCB ، پشته کاربر ، پشته هسته دارند.
    بلوک کنترل نخ ساختمان داده نخ است که شامل : شناسه نخ ، حالت ، اولویت ، شمارنده برنامه ، اطلاعات وضعیت پردازنده و ... است.
    پشته کاربر برای فراخوانی رویه ها و توابع برای ارسال پارامتر و برگشت است.
    پشته هسته به معنای اجرای هسته در بین اجرای فرآیند است. (این یک مطلب بسیار مهم است)
    موارد اشتراکی:
    بلوک کنترل فرآیند و فضای آدرس کاربر
    از طریق فضای آدرس کاربر نخ ها می توانند باهم ارتباط برقرار کنند و هر تغییری در فضای آدرس کاربر برای همه نخ ها قابل دید است.
    از طریق بلاک کنترل فرآیند امکان دسترسی به منابع فرآیند برای نخ ها میسر است.
    2- منظور شما واضح نیست.چه خطایی؟
    3- نخ های فرآیند پدر کاملاً مستق از فرآیند فرزند عمل می کند.سیستم عامل ویندوز از همین رویکرد نیز استفاده کرده است.
  • ۰۶ تیر ۹۳ ، ۲۱:۵۵
  • عماد رضوانی
    • ۱. منظور ساختمان داده نخ ها نبود و ساختمان داده ای بود که بین چند نخ بصورت اشتراک هست.
    ۲. بعضی از سیستم عامل ها یک متغیر بافر برای آخرین خطا دارد. اگر چند نخ بصورت همزمان خطا ایجاد کنند نتیجه چیست.
    ۳. (برگرفته از منبع آموزشی). اگر فرایند پدر دارای چند نخ باشد  فرایند فرزند نیز باید اینگونه باشد؟ اگر نباشد آیا فرایند به درستی وظایفش را انجام می دهد؟(با توجه به ضروری بودن همه نخ ها). به هر حال اگر فرایند فرزند نبز همان چند نخ متعلق به پدر را دارا باشد و در هنگام یک فراخوانی مانند read از صفحه کلید یک از نخ ها بلوکه شود چه پیش می آید؟ آیا هر دو نخ روی صفحه کلید بلوکه می شوند؟ آیا وقتی یک خط تایپ می شود هر دو نخ کپی آن را دریافت می کنند؟!
    در کل چالش کار مد نظر هست و جواب این سوالها با توضیح قابل حل هست.
  • ۰۶ تیر ۹۳ ، ۲۲:۲۱
  • لونا
    • 1- اشتراک بین نخ ها از طریق فضای آدرس کاربر انجام می شود.
    2- اداره کردن خطاها وابسته به نوع خطا است ، تا نوع خطا مشخص نشود اداره کردن آن امکان ندارد.
    مثلاً اگر خطا دسترسی غیرمجاز به یک مکان حافظه است ، با رویکردهای قدیمی تر ، خروج کل فرآیند از سیستم است که در سیستم های جدید اینطور نیست.
    3 - چند نخی مسئله نیاز در برنامه نویسی است که به برنامه بستگی دارد.همیشه حتماً برنامه نباید چند نخی باشد ، یا یا فرآیند زایش انجام دهد.اما اگر براساس تصور شما در نظر بگیریم ، فرآیند والد ، باید فرآیند فرزندش را کنترل کند و حتی این امکان برای فرآیند والد وجود دارد که فرآیند فرزند را خاتمه دهد حتی در زمان اجرا.شاید فرآیند والد فقط نیاز به چند نخی برای امور دیگری داشته باشد و فرآیند فرزند نیاز نداشته باشد.برای فرآیند فرزند همان تکلیفی که مشخص شده است باید انجام دهد.مسئله ارث بری در فرآیند فرزند بستگی به فرآیند والد دارد چون برای فرآیند فرزند احتمال خطا بیشتر است به همین دلیل فرآیند والد همچنان باید مراقب فرزند خود باشد.زمانی که به صورت ارث بری فرآیند فرزند از والد نخ ها را به ارث می برد این فرآیند والد است که باید اجازه دهد که فرزندش از نخ ها چه زمانی استفاده کند.وگرنه تداخل ایجاد می شود و منطقی نیست دو نخ یکسان باهم اجرا شوند البته باید پردازش را نیز در نظر گرفت چون که در سیستم های تک پردازنده ای در هر لحظه یک نخ قابل اجرا است در حالیکه در سیستم های چند پردازنده ای هسته می تواند روی تمام پردازنده ها نخ ها را زمانبندی کند.ضمناً بستگی دارد که این نوع ارث برای براساس نمونه سازی باشد یا استاتیک.که هرکدام رویکرد جداگانه ای دارند.
  • ۰۷ تیر ۹۳ ، ۰۴:۰۷
  • لونا
    • نگاهی به همزمان سازی درونی
    در بحث مدیریت حافظه همزمان سازی جزء مهمترین مسائل محسوب می شود.ضمن اینکه با وجود رویکرد چند نخی ، این مفهوم انعطاف بیشتری گرفته است.تقریباً موارد متعددی وجود دارد که بر مسئله همزمانی کمک می کنند.اما با وجود مسئله ای مانند وقفه باید در طراحی الگوریتم های همزمانی ، دقت بیشتری کرد. وقت پردازنده و مسئله چندبرنامگی باید در مسئله هم زمانی در نظر گرفت.از طرف دیگر دخالت های ناخواسته فرآیندها دیگر در فضای سایر فرآیندها باعث مشکلاتی می شود که مستعد خطاهای ناخواسته می شود.مسئله ارتباط فرآیندها و نوع همکاری نیز در همزمانی مطرح است اینکه باید دانست قرار است چه نوع همکاری بین فرآیندها صورت گیرد.ضمن اینکه باید مسائلی مانند تاثیر بر روی فرآیندها و مسائل بالقوه حین ارتباط را نیز در نظر گرفت.تاثیر روی فرآیندها تاکید بر وابستگی و استقلال فرآیندها از یکدیگر دارد و مسائل بالقوه بر رسیدن به حق فرآیند ، عدالت ، رعایت قواعد همزمانی تاکید دارد.هنگامیکه منابع به صورت اشتراکی استفاده می شود هر فرآیند برای دسترسی به منابع باید از یک نقطه خاص شروع کند که به آن ناحیه بحرانی می گویند.در این ناحیه باید به فرآیند اطمینان داد که اشتراک از طریق همکاری یا غیرهمکاری مشکلاتی در تغییر داده ها صورت نمی دهد.از این ملزوماتی برای هماهنگی و شفاف سازی مطرح شد که طراح الگوریتم باید آنها در نظر بگیرد.این ملزومات بر دسترسی فرآیند به ناحیه بحرانی خود تاکید دارد.و برای آن محدودیت هایی در نظر گرفته شده است. بعدها با رویکردهای مطرح شده آشنا خواهیم شد.
  • ۰۷ تیر ۹۳ ، ۰۷:۲۹
  • لونا
    • نگاهی به رویکرد ارتباط بین فرآیندها با لوله pipe در یونیکس
    لزوم ارتباط بین فرآیندها جهت همکاری در سیستم عامل یونیکس به مانند مدل تولیدکننده و مصرف کننده طراحی شد.این کار از طریق یک کانال ارتباطی که ایجاد می شود صورت می پذیرد.بعدها در مورد روش دیگر صحبت خواهیم کرد.اما در یونیکس فرآیندها می توانند با فراخوانی read و write با هم ارتباط برقرار کنند.اما لوله چیست؟
    لوله یک بافر چرخشی (دایره ای) است که از طریق آن دو فرآیند می توانند مبتنی بر مدل تولیدکننده و مصرف کننده با هم ارتباط برقرار کنند.این تشکیل یک FCFS را می دهد.
    اندازه لوله در زمان ایجاد لوله و به صورت ثابت تعیین می شود.فرآیندی که در خواست write را در بافر صادر می کند ممکن است به حالت مسدود برود.زیرا این بافر مبتنی بر قواعد انحصار متقابل است.
    filep = pipe()
    این دستور ایجاد یک لوله در سیستم یونیکس است که دراینجا filep نقش توصیفگر فایل را بر عهده دارد.در این حال یک کانال برای ارتباط بین دو فرآیند ایجاد می شود.
    لوله ها تنها راهکار هم زمانی در یونیکس نیستند.از حافظه مشترک ، سمافور ، پیام ، مانیتور نیز استفاده می شود.
    که هر کدام راهکار مخصوص به خود را دارند.به عنوان مثال در مدل پیام ، سیستم مانند یک صندوق پستی عمل می کند.
    و پیام داری قالب است که قابل آن شامل یک header و body است.که می توان در آن از مدل FCFS استفاده کرد.
    حافظه مشترک معمولاً سریع تر از سایر روش ها است.ولی به عنوان مثال در فرآیندهای بی درنگ قبلاً از حافظه مشترک استفاده می شد ولی از لوله در برای فرآیندهای غیر بی درنگ می شد.
    پاسخ:
    PIPE
  • ۰۸ تیر ۹۳ ، ۰۰:۳۹
  • Luna Luna
    • مجموعه کاری و حافظه مجازی
    کاربردهای تخصیص ، براساس تصمیم گیری های مختلفی انجام می شود به عنوان نمونه تصمیم گیری در زمان ایجاد فرآیند ، براساس تابع تقاضای برنامه.یا براساس یک خطای صفحه (در صورت نبودن صفحه در حافظه) صفحه مورد نظر انتخاب و جایگزین می شود.یا براساس یک زمان خاصی سیستم به بررسی کارائی صفحه های تخصیص داده شده به فرآیندها می پردازد و براساس آن تصمیم گیری هایی اتخاذ می شود که آیا تخصیص افزایش یا کاهش یابد.
    رویکرد مجموعه کاری یک مکانیزم تخصیص متغیر است که تاثیر زیادی در برنامه ریزی برای حافظه مجازی دارد.مجموعه کاری شامل زیر مجموعه ای از فضای آدرس مجازی فرآیندها است که به طور فیزیکی مقیم هستند.
    مجموعه کاری از دو پارامتر استفاده می کند:
    Δ = فرآیند در زمان مجازی t
    t = زمان مجازی
    پس می توان یک تابع برای مجموعه کاری با دو پارامتر working_set(Δ,t) داشت.

    نتیجه این تابع داشتن مجموعه ای از صفحه های یک فرآیند است که در زمان Δ اخیر به مجموعه آنها رجوع شده است.
    اگر دنباله ای از مراجعات به حافظه را به صورت زمان مجازی در نظر بگیریم و آن را با تابع r(n) نشان دهیم برای n=1,2,3,... پس صفحه n(i) آدرس مجازی nام است که مربوط به یک فرآیند است.
    زمان مجازی در این تابع براساس مراجعه به حافظه تخمین زده می شود.
    تعیین اندازه پنجره به عنوان پنجره ای از زمان که برابر متغیر Δ است.
    با تعیین دنباله ای از مراجعات به صفحه یک فرآیند ، و با بزرگ تر شدن اندازه پنجره ، مجموعه کاری بزرگتر می شود.
    پس می توان به رابطه زیر دست یافت:
    working_set(t,Δ+1) ⊇ w (t,Δ).
    به این مطلب بعداً به طور مفصل خواهم پرداخت.
  • ۰۸ تیر ۹۳ ، ۰۰:۵۵
  • لونا
    • تعیین اولویت و زمانبندی RR
    در سیستم عامل هایی مانند ویندوز زمانبندی براساس تعیین اولویت پویا است تا بتواند به نیازهای یک کاربر در سیستم پاسخ دهد.چون که هسته مدل پیوندی است پس این نیازهای باید برای خدمتگذار نیز پاسخ داده شود.ویندوز از یک زمانبند غیر انحصاری استفاده می کند و طوری طراحی شده است که می تواند اولویت ها را پویا طبقه بندی کند و از یک زمانبند RR برای هر طبقه استفاده کند ، اما تعیین و تغییر اولویت براساس فعالیت های نخ جاری انجام می شود.یعنی سیستم نخ را بررسی کرده و فعالیت های آن را زیر نظر دارد و بعد تصمیم گیری می کند که اولویت آن چگونه تعیین شود.
    به طور کلی تعیین و تغییر اولویت ها با ترکیب زمانبندی های دیگر می تواند بهتری از استفاده مستقیم از تنها یک زمانبندی بدست دهد.
    نظر شما راجع به این روش چیست؟
  • ۰۸ تیر ۹۳ ، ۰۲:۴۹
  • لونا
    • نیازمندی های تعریف فرآیند برای سیستم عامل
    از امروز به بعد سعی می کنم که نیازمندی های سیستم عامل را به صورت شبه کد (نه خود کد) به شما معرفی کنم.برای شروع تعریف فرآیند را آغاز می کنم.
    ضمناً این تعریف صرفاً آموزشی است و به تعریف دقیق فرآیند نمی پردازد.بعدها حتماً به تعریف دقیق فرآیند به صورت کاملاً تصویری خواهم پرداخت.
    در پست بعدی تا دقایقی دیگر این نیازمندی را تعریف خواهم کرد.
  • ۰۸ تیر ۹۳ ، ۰۵:۰۲
  • لونا
    • نیازمندی های تعریف فرآیند برای سیستم عامل
    ابتدا تعریف فرآیند در یک struct
    َشبه کد
    struct process
    بلاک کنترل فرآیند از پنج بخش تشکیل شده است:
    1- شناسه فرآیند
    * شناسه فرآیند: مقدار منحصر به فردی که به یک فرآیند داده می شود تا از سایر فرآیندها متمایز گردد.
    شبه کد
    char p_ID[LEN]
    * شناسه فرآیند والد: در صورتی که این فرآیند فرزند باشد باید شناسه فرآیند والد مشخص گردد.
    شبه کد
    cahr p_FID[LEN]
    نکته: می توان از اشاره گر به جای تعریف متغیر جداگانه استفاده کرد.
    * شناسه کاربری: نام کاربری که به فرآیند دسترسی دارد.
    شبه کد
    char p_userID[LEN]
    --------------------------------------------------------------------------------------------------------------------------------------

    2 - وضعیت پردازنده : این اطلاعات شامل ثبات هایی که کاربر می تواند آن را مشاهده کند و در حالت کاربر اجرا می شوند و کاربر می تواند به آنها رجوع کند.بستگی به نوع پیاده سازی پردازنده ، تعداد ثبات ها متغیر است.دسترسی به این ثبات ها از طریق دستورالعمل های ماشین است.
    * ثبات های داده : بسته به عملیات متفاوت است.
    * ثبات های آدرس: آدرس داده ها و دستورالعمل ها که به صورت کلمه از حافظه اصلی خوانده می شود.ممکن است برای بدست آوردن آدرس ها از این ثبات استفاده شود که باز بسته به عملیات متفاوت است.
    * ثبات شاخص: آدرس دهی با عملیات جمع یک شاخص با آدرس پایه برای بدست آوردن آدرس موثر است.
    ----------------------------------------------------------------------------------------------
    * ثبات های کنترل وضعیت: کنترل عملیات روی پردازنده است و شامل:
     - شمارنده برنامه: آدرس دستورالعمل بعدی
    - کدهای وضعیتی: نتایج آخرین عملیات ها در محاسبات یا عملیات های منطقی مانند سریز ، تقسیم بر صفر ، و ...
    - وضعیت: flag هایی باری مدیریت وقفه ها مانند فعال سازی و غیر فعال سازی وقفه
    شبه کد
    char f_cod_Interrupt
    شبه کد برای ثبات ها
    برای هر کدام از موارد بالا می توان یک struct تعریف کرد که داده ها را نگه داری کند. به غیر از مورد آخر.
    --------------------------------------------------------------------------------------------------------------------------------------
    3- اشاره گر به پشته ها: این پشته ها حاوی پارامترها ، آدرس روال های برای فراخوانی و ... است.
    شبه کد
    تعریف struct از نوع اشاره گر و اشاره به بالای هر پشته.
    --------------------------------------------------------------------------------------------------------------------------------------
    4 - کنترل فرآیند: شامل اطلاعات زمانبندی و رفتار فرآیند.
    * رفتار فرآیند: وضعیت فرآیند را نشان می دهد که مورد استفاده برای الگوریتم های زمانبندی است مانند حالت اجرا ، انتظار ، مسدود ، تعلیق و...)
    شبه کد
    int p_mode
    * الویت فرآیند: چنانچه سیاست تخصیص اولویت برای فرآیند در نظر گرفته شده باشد.از این مقدار برای تصمیم گیری های زمانبندی استفاده می شود.
    شبکه کد
    char p_prt
    * حسابداری: برخی اطلاعات مربوط به پروسه زمانبندی مانند مدت زمان انتظار فرآیند و ...
    از این اطلاعات برای تخمین کارایی سیستم و تصمیم گیری برای زمانبندی های بعدی استفاده می شود.
    شبه کد
    می توان یک struct تعریف کرد که داده ها را نگه داری کند.
    * رویداد: مشخصه رویدادی که فرآیند برای آن به حالت انتظار رفته است.
    شبه کد
    char p_evd[LEN]
    * سایر اطلاعات
    - اشاره گر به صف: چنانچه سیستم از صف برای تعیین اولویت استفاده کرده است مانند سیستم عامل ویندوز
    - و ...
    * ارتباطات بین فرآیندها
    - بستگی به نوع ارتباط دارد: لوله ، پیام ، سمافور ، مانیتور ، و ... باید علائمی در این بخش تعریف شود که نشانگری برای ارتباط بین فرآیندها باشد.
    * مجوز فرآیند: اجازه به فرآیند برای اجرای بعضی از دستورالعمل ها و ...
    * مدیر حافظه: اشاره گر به جداول صفحه و قطه در سیستم حافظه مجازی.
    شبه کد
    تعریف یک اشاره گر به جداول صفحه یا قطعه
    چون که جداول صفحه و قطعه شامل مقادیر عددی هستند من در شبه کد از اشاره گری از نوع عددی استفاده می کنم.
    نکته: ممکن است به صورت دیگر و از نوع دیگر تعریف شود.
    numberType *entry_number_p_page
    * منابع: تعیین اینکه فرآیند مالک چه منابعی است.
    ---------------------------------------------------------------------------------------------------
    بازهم تاکید می کنم که این ساختمان داده فرآیند که تعریف شد فقط کمی شبه کد و توضیح داشت بعداً به طور مفصل توضیح داده خواهد شد.
  • ۰۸ تیر ۹۳ ، ۰۶:۵۳
  • لونا
    • نیازمندی های تعریف فرآیند برای سیستم عامل - نخ
    موارد زیر در داخل فرآیند بخش قبل است.

    1 - بلوک کنترل نخ: به مانند فرآیند می باشد با کمی تفاوت.
     * وضعیت نخ : تعریف حالت نخ (تمامی موارد فرآیند به جزء تعلیق)
     * کنترل نخ (متن نخ):در بخش فرآیند توضیح داده شده است.
     * پشته کاربر: که همان اشاره گر به پشته ها می باشد.
     * پشته هسته : پشته برای فراخوانی های هسته ، اگر هسته در بین نخ ها در فرآیند اجرا می شود.
     نکته : پشته هسته در بخش فرآیند گفته نشد زیرا مدل حالت فرآیند مشخص نبود و معمولاً به صورت کلاسیک آورده نمی شود مگر آنکه مدل حالت فرآیند انتخاب شده باشد.
     * حافظه static برای متغیرهای محلی نخ
     شبه کد
    توضیح: اشاره گری به مکان حافظه.
    ساخت وبلاگ در بلاگ بیان، رسانه متخصصان و اهل قلم