Түгжрэл

1. CS207
Үйлдлийн систем
Лекц 9
Төслийн багт ажиллах зөвлөгөө/ Пр-уудын
хамтын ажиллагаа ба түгжрэл
А.Хүдэр, Э.Мөнхсүх
http://www.elearn.sict.edu.mn

2. Lec 9.29/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Мониторын тодорхойлолт
• Хоёрдмол зорилготой учир семафор нь ойлгоход төвөгтэй:
– Солбилцол болон төлөвлөлтийн хязгаарлалтан дээр
хэрэглэгддэг.
– Зөв санаа: Солбилцол дээр түгжээ хэрэглээд төлөвлөлтийн
хязгаарлалт дээр нөхцөлт хувьсагчид хэрэглэе.
• Монитор: Дундын өгөгдөл руу паралелиар хийх
хандалтыг удирдах нэг цоож, 0 болон олон нөхцөлт
хувьсагчид
– Монитор ашиглах нь програмчлалын парадигм юм
• Цоож: Дундын өгөгдлийг солбилцолоор хангадаг:
– Дундын өгөгдөл рүү хандахаас өмнө үргэлж эзэмшинэ
– Дундын өгөгдөл рүү хандаж дуусаад үргэлж чөлөөлнө
• Нөхцөлт хувьсагч: эгзэгтэй муж дотор ямар нэг зүйл болохыг хүлээж
байгаa хуулбаруудын дараалал
– Гол санаа: эгзэгтэй муж дотор унтах үедээ цоожийг атомаар
чөлөөлөхийг зөвшөөрнө
– Семафортой харьцуулахад: эгзэгтэй муж дотор хүлээж чадахгүй

3. Lec 9.39/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Монитортой програмчлах
• Монитор нь програмын логикийг харуулдаг
– Шаардлагатай бол хүлээх
– Ямар нэгэн өөрчлөлт гарахад дохио өгдөг учир хүлээж
байгаа ямарч хуулбар процесс цааш үргэлжилнэ
• Мониторд суурилсан програмын үндсэн бүтэц
lock
while (need to wait) {
condvar.wait();
}
unlock
do something so no need to wait
lock
condvar.signal();
unlock
Check and/or update
state variables
Wait if necessary
Check and/or update
state variables

4. Lec 9.49/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Агуулга
• Төслийн багт програмчлал хийх зөвлөгөө
• Синхрончлолыг дэмждэг хэлүүд
• Түгжрэл
– Түгжрэлийн үүсэх шалтгаан
– Түгжрэлээс зайлсхийх болон таслан зогсоох шийдлүүд
Note: Some slides and/or pictures in the following are
adapted from slides ©2005 Silberschatz, Galvin, and Gagne.
Many slides generated from my lecture notes by Kubiatowicz.

5. Lec 9.59/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Төслийн багт програмчлал хийх зөвлөгөө
• Том төсөлд нэгээс илүү хүн шаардлагатай цаг
хугацааны хувьд ч мөн адил
– Том ҮС: нэг хүн хийвэл 1000 жил
• Програм хангамжийн төслийн багуудыг үр
дүнтэй ажиллуулахад маш хэцүү байдаг
– Үүнийг барилга барихтай адилтгаж
ойлгож болохгүй.
» Хааны барилга барихад нэг жил:
Төмрийг 1600 км цаанаас зөөсөн.
» Гувер-ийн далан: Ажилчдын хот
барьсан.
– Төслийн эцсийн хугацааг хэтрүүлэх нь
зүгээр үү?
» Бид хугацааг сунгадаг. (Сунгасан
өдөр)
» Бодит байдал: Зах зээл дээрх хугацаа
нь хамгийн чухал зүйлсийн нэг юм!
Тиймээс сунгах гэдэг бол их үнэтэй
болно.
“You just have
to get your
synchronization right!”

6. Lec 9.69/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Том төсөл
• Том төсөл гэж юу вэ?
– Хугацаа болон ажлын үнэлгээ нь хатуу байдаг
– Програмчид нь байнгын эерэг үзэлтэй
(Энийг хоёр өдөрт л хийх болно.)!
» Тиймээс лабораторийн ажлаа эртхэн эхлүүлэхийг шахаж
байдаг.
» Төгсөх ангийн оюутан ямар нэгэн алдааг засахад 10 минут л
хангалттай гэж хэлж байсан гэтэл 2 цаг . . .
• Төслийг яаж үр ашигтай хуваах вэ?
– Хүн нэмэгдэх тусам хуваагддаг даалгаврууд багасна.
– Гэвч, харилцаа холбоо шаардлагатай гэвэл:
» Хугацаа хамгийн бага хязгаартаа хүрнэ.
» Харилцаа ихэсвэл хугацаа нэмэгдэнэ!
– The Mythical Man-Month номын асуудал:
» Төсөл хэр удаан үргэлжилхийг тооцоолж байгаа.
» Хугацаандаа амжихгүй болоод ирвэл хүн нэмнэ.
» Төсөлд тооцоолсноос илүү цагийг зарцуулах болно!

7. Lec 9.79/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Даалгаврыг хуваах арга техник
• Функциональ-аар
– A хүн хуулбарыг, B хүн семафорыг, C хүн цоожийг хэрэгжүүлнэ…
– Асуудал: API-аар дамжуулан маш их харилцаа хийгддэг.
» Хэрэв B хүн API – г өөрчилвөл А хүн өөрчлөлт хийх хэрэгтэй
» Түүх: Агаарын тээврийн компани цагийн хуваарь гаргах
болон захиалга хийх системд $200 сая зарцуулсан. “2 баг хамт
ажилласан”. 2 жилийн дараа, програмуудаа нэгтгэхээр очсон
боловч бүтэлгүйтсэн. Учир нь интерфэйс нь өөрчлөгдсөн
байсан (баримт бичигт оруулсан боловч хэн ч анзаараагүй).
Үр дүнд: Дахин засахад $200 сая зарлагадсан.
• Үүрэг даалгавар-аар
– A хүн дизайн, B хүн код бичих, C хүн тестлэх
– Тэнцвэртэй байдлыг олоход хэцүү байж магадгүй, гэвч
хүмүүсийнхээ хүчин чадалд анхаарах хэрэгтэй
– Зүгшрүүлэлт бол хэцүү ажил учраас Microsoft нь програм тус
бүрт 2 тестлэгчтэй байдаг.

8. Lec 9.89/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Харилцаа холбоо
• Олон хүнтэй болох тусам их харилцаа үүснэ.
– Өөрчлөлтийг илүү их хүн-д түгээх хэрэгтэй болдог
– Код бичиж байгаа хүнийг системийн хамгийн доод суурь
бүрэлдэхүүн гэж бод. Учир нь хүн бүр түүнээс хамаарна.
• Буруу ойлголт их гардаг.
– “Индекс 0 ээс эхэлдэг үү? Би чамайг 1 гэж хэлсэн гэж
бодсон!”
• Шийдвэрийг хэн гаргадаг вэ?
– Бие даасан шийдвэрүүд нь хурдан гардагч алдаатай байдаг
– Багаар шийдвэр гаргах нь цаг хугацаа их шаарддаг
– Төвлөрсөн шийдвэр нь өргөн хүрээгээр авч үзэхийг
шаарддаг (хэн нэгэн нь “Систем архитектур” байх)
• Ихэнх тохиолдолд хэн нэгнийг системийн архитектур
болгож томилох нь зөв шийдвэр байдаг.
– Найдвартай хүн байх
– Хүнтэй харьцах чадвар сайтай байх
– Хүмүүсд ажил хийх боломжийг олгох

9. Lec 9.99/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Зохицуулалт
• Олон хүн  хэн нь ч бүх уулзалтанд оролцож чадахгүй!
– Тэд шийдвэр болон хэлэлцүүлэгүүдээс хоцорно.
– Өмнөх жишээнээс харахад: нэг хүн хурлаа таслаад нэг ажил
хийжээ. Гэвч тэр ажил нь хурлаар цуцалсан ажил байсан.
– Яагаад багаа 5 хүнээр хязгаарладаг вэ?
» Ө.х хэзээ ч уулзалтын цагаа төлөвлөх боломжгүй
– Яагаад хамгийн багадаа 4 хүн шаарддаг вэ?
» Бодит байдалд бэлэн туршлагатай баг байх хэрэгтэй
• Хүмүүс өөр өөр ажлын хэв маягтай байдаг
– Зарим нь өглөө зарим нь шөнө ажилладаг
– Багийхантайгаа хэзээ уулзаж хэзээ хамт ажиллах вэ гэдгээ та
хэрхэн шийддэг вэ?
• Төслийн уналтын тухай?
– Энэ нь зайлшгүй тохиолддог!
– Ж нь: 4 шатанд хүн бүр ярих ч завгүй байжээ. Нэг хүн
хоцорвол хэн ч түүнийг дууссан дуусталаа мэдэхгүй.
• Бүрдсэн багт нэмж хүн авах хэцүү байдаг
– Гар нийлсэн байдаг

10. Lec 9.109/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Хэрхэн ажиллуулах вэ?
• Хүмүүс бол хүн юм. Үүнийг хүлээн зөвшөөр.
– Хүмүүс алдаа хийнэ уулзалтаа тасалдаг, дуусах хугацаагаа
мартдаг г.м. Та үүнтэй дасан зохицох хэрэгтэй
– Асуудлыг урьдаас төлөвлөх нь бүх зүйл өнгөрсний дараа
алдаагаа засахаас илүү дээр.
• Баримтжуулах, баримтжуулах, баримтжуулах
– Яагаад баримтжуулдаг вэ?
» Шийдвэрийг илтгэх болон бусдад мэдээллэх
» Алдааг эрт олж харах нь амар байдаг
» Үйл явцийг үнэлэхэд хялбар
– Баримтад юу агуулагддаг вэ?
» Бүх зүйл (Хэтэрхий их бол хүн уншихгүй)
– Стандартчилах!
» Програмчлалын нэг формат: хувьсагчийн нэрийг бичихдээ,
догол мөр авах г.м.
» Тайлбар (Шаардлага, үр нөлөө, өөрчлөлт)—javadoc?

11. Lec 9.119/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Танд зөвлөсөн болон оноогдсон баримтыг
цуглуулах
• Төслийн зорилго: зорилт, шаардлага, зэрэглэл
• Шаардлага: гүйцэтгэлийн болон бусал шаардлагууд
– Энэ нь үүссэн хамгийн анхны баримт бичиг бөгөөд
хамгийн сүүлд дуусгадаг.
• Уулзалтын тэмдэглэл
– Бүх шийдэрийг баримтжуулах
– Дизайн баримт руу cut & paste хийж болно
• Цагийн хуваарь: Таамагласан хугацаа?
– Энэ баримт нь маш чухал!
• Зохион байгуулалтын хүснэгт
– Тухайн даалгаварыг хэн хариуцах вэ?

12. Lec 9.129/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Програм хангамжийн хэрэгсэл
• Эх кодын хувилбарыг хянах програм
– (Дэд хувилбар, CVS, бусад…)
– Үйлдлээ буцааж түүхийг харан алдааг засах
– Хаана яагаад алдаа гарсныг тогтоох
– Өөрчлөлтийг хүн бүрт танилцуулах (CVS’s нэмэлт
боломжийг ашиглах)
• Автомат шалгагч хэрэгслийг ашиглах
– Интерактив бус програмуудад зориулж скрипт бичих
– JUnit: нэгжийн тестийг автоматжуулах
– Microsoft Vista үйлдлийн системийн цөмийг шөнө болгон
хөрвүүлдэг байсан. Хүн болгон сүүлийн хувилбарыг
ажиллуулж туршдаг.
• И-Мэйл болон чатыг зохистой хэрэглэж түүх үлдээ

13. Lec 9.139/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Үргэлж тестэл
• Нэгтгэсэн тестийг зөвхөн өмнөх шөнө нь биш үргэлж
хийх!
– Энгийн жижигхэн функц бичих
» Хүмүүсээр үргэлж тестлүүлэх мөн их ажиллуулах
– Нэгдсэн тестүүдийн хуваарийг төлөвлөх
» Бүх хүмүүсээ цуглуулаад кодоо шалгаад хөрвүүлээд тестэл.
» Оройтох хүртэл нь бүү хүлээ!
• Тестийн төрлүүд:
– Нэгжийн тест: Модуль бүрийг тусгаарлан шалгана (use
JUnit?)
– Демон: Кодыг онцгой тестүүдээр шалгана
– Санамсаргүй тест: Кодыг санамсаргүй тестээр шалгах
• Тестийг өмнө нь дараа нь дахин дахин тестэл
– Нэг тестлээд л мартах хандлагатай байдаг; Кодын ямар нэг
хэсэг дээр өөрчлөлт гарвал яах вэ?

14. Lec 9.149/29/10 Kubiatowicz CS162 ©UCB Fall 2010
С хэлний синхрончлолын дэмжлэг
• C хэл: Синхрончлол нь шууд утгатай байдаг
– Эгзэгтэй мужаас гарах кодын бүх замийг мэдэх эсэхээ
баталгаажуул
int Rtn() {
lock.acquire();
…
if (exception) {
lock.release();
return errReturnCode;
}
…
lock.release();
return OK;
}
– setjmp/longjmp аас болгоомжил!
» Функцээс гарах глобал үсрэлт хийж магадгүй
» Дээрх жишээнд E функц нь longjmp – ийг дуудаад B функц
руу очино
» С функц нь lock.acquire – ийг хийдэг бол асуудал үүснэ!
Proc A
Proc B
Calls setjmp
Proc C
lock.acquire
Proc D
Proc E
Calls longjmp
Stackgrowth

15. Lec 9.159/29/10 Kubiatowicz CS162 ©UCB Fall 2010
С++ хэлний синхрончлолын дэмжлэг
• C++ шиг онцгой тохиолдолтой хэлүүд
– Онцгой тохиолдолтой хэлүүд асуудалтай байдаг (цоожоо
чөлөөлөлгүйгээр глобал гарах үйлдлийг хялбар хийж болдог)
– Доорхийг авч үзье:
void Rtn() {
lock.acquire();
…
DoFoo();
…
lock.release();
}
void DoFoo() {
…
if (exception) throw errException;
…
}
– DoFoo() функц доторх онцгой тохиолдол нь цоожийг
чөлөөлөлгүйгээр гарна

16. Lec 9.169/29/10 Kubiatowicz CS162 ©UCB Fall 2010
C++ Language Support for Synchronization (con’t)
• Эгзэгтэй муж дах бүх онцгой тохилдлуудыг барьж авах ёстой
– Онцгой тохиолдолоо барьж аваад, цоожоо чөлөөлөөд, онцгой
тохиолдолоо үүсгэнэ:
void Rtn() {
lock.acquire();
try {
…
DoFoo();
…
} catch (…) { // catch exception
lock.release(); // release lock
throw; // re-throw the exception
}
lock.release();
}
void DoFoo() {
…
if (exception) throw errException;
…
}
– Илүү сайн шийдэл: авто_ptr<T> - тэй хэрэгслийг ашигла. C++ ном
унш.
» Exit функцээс хамааралгүйгээр цоожийг чөлөөлж дахин
хуваарилах боломжтой

17. Lec 9.179/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Жава хэлний синхрончлолын дэмжлэг
• Жава нь хуулбар болон хуулбарын синхрончлолыг
илэрхий дэмждэг
• Bank Account example:
class Account {
private int balance;
// object constructor
public Account (int initialBalance) {
balance = initialBalance;
}
public synchronized int getBalance() {
return balance;
}
public synchronized void deposit(int amount) {
balance += amount;
}
}
– Обьект болгон өөрийн цоожтой байна. Цоож нь synchronized
арга руу ороход болон гарахад автоматаар эзэмшигдэх ба
чөлөөлөгдөнө.

18. Lec 9.189/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Жава хэлний синхрончлолын дэмжлэг (үргэлжлэл)
• Жава хэлний synchronized үйлдэл:
synchronized (object) {
…
}
– Жава обьект болгон өөрийн гэсэн цоожтой байдаг учраас
энэ үйлдлийн бие рүү ороход болон гарахад обьектийн
цоож нь эзэмшигдэх болон чөлөөлөгдөнө
– Онцгой тохиолдолтой хамт хэрэглэгдэж болно:
synchronized (object) {
…
DoFoo();
…
}
void DoFoo() {
throw errException;
}

19. Lec 9.199/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Жава хэлний синхрончлолын дэмжлэг (үргэлжлэл)
• Жавагийн обьект болгон цоожноос гадна нэг нөхцөлт хувьсагчтай байна
– Синхрончлогдсон арга болон блок дотор хэрхэн хүлээх үйлдэл хийх вэ:
» void wait(long timeout); // Wait for timeout
» void wait(long timeout, int nanoseconds); //variant
» void wait();
– Синхрончлогдсон арга болон блок дотроос хэрхэн сигнал үйлдэл хийх вэ:
» void notify(); // wakes up oldest waiter
» void notifyAll(); // like broadcast, wakes everyone
– Нөхцөлт хувьсагчид нь хязгаарлагдмал хугацаанд хүлээж чадна. Энэ нь
онцгой тохиолдлыг боловсруулахад хэрэгтэй юм:
t1 = time.now();
while (!ATMRequest()) {
wait (CHECKPERIOD);
t2 = time.new();
if (t2 – t1 > LONG_TIME) checkMachine();
}
– Жавагийн бүх VM ижил байдаггүй!
» Төлөвлөлтийн бодлого нь ялгаатай, заавал зэрэглэлтэй байх албагүй!

20. Lec 9.209/29/10 Kubiatowicz CS162 ©UCB Fall 2010

21. Lec 9.219/29/10 Kubiatowicz CS162 ©UCB Fall 2010
• Нөөц – хуулбаруудад ажиллахад нь хэрэг болдог
идэвхигүй зүйлс юм
– CPU time, disk space, memory
• Хоёр төрлийн нөөц:
– Хүчээр суллагдах – Булааж авч болно
» CPU, Embedded security chip
– Хүчээр суллагдахгүй – Хуулбараас нь салгаж болохгүй
» Дискний зай, принтер, виртуал санах ойн орон зайн хэсэг
» Солбилцол – Эгзэгтэй муж руу орох эрх
• Нөөц нь тусгай хандалттай эсвэл дундын хандалттай
байж болно.
– Зөвхөн унших файлууд нь ихэвчлэн дундынх байна.
– Принтер нь хэвлэж байх үедээ дундынх байж болохгүй.
• Үйлдлийн ситсемийн гол үүргүүдийн нэг нь нөөцийн
удирдлага юм.
Нөөц

22. Lec 9.229/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Гачигдал ба Түгжрэл
• Гачигдал ба Түгжрэл
– Гачигдал: Хуулбар тодорхойгүй хугацаагаар хүлээнэ.
» Ж нь, өндөр зэрэглэлтэй хуулбаруудын ашиглаж байгаа
нөөцийг бага зэрэглэлтэй хуулбарууд хүлээдэг.
– Түгжрэл: нөөцийг тойргоор хүлээдэг
» Thread A owns Res 1 and is waiting for Res 2
Thread B owns Res 2 and is waiting for Res 1
– Түгжрэл  Starvation but not vice versa
» Гачигдал төгсөж болно (төгсөхгүй ч байж болно)
» Түгжрэл гадны нөлөөгүйгээр төгсөж чадахгүй
Res 2Res 1
Thread
B
Thread
A
Wait
For
Wait
For
Owned
By
Owned
By

23. Lec 9.239/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Түгжрэлийн нөхцөл
• Түгжрэл нь байнга детерминистик байдаггүй – Ж нь 2 mutex:
Thread A Thread B
x.P(); y.P();
y.P(); x.P();
y.V(); x.V();
x.V(); y.V();
– Дээрх кодон дээр дандаа түгжрэл үүсэхгүй байх болно
» Яг зөв хугацаатай байх ёстой (“буруу” хугацаа?)
» Та нэг програм хангамжийг хийгээд тестлээд гаргасан тэр нь
цөмийн цахилгаан станцийн удирдлага дээр ажилладаг. . .
• Түгжрэл нь олон тооны нөөцтэй үед гарна
– Асуудал гарвал хэсэгчлэн авч үзэж чадахгүй
– Нөөц бүрийн хувьд түгжрэлийг тус тусад нь шийдэж чадахгүй
• Ж нь: 2 дисктэй болон 2 хуулбартэй систем
– Хуулбар бүрт үйлдлийг удирдах 2 диск шаардлагатай
– Хуулбар бүр 1 дискийг авч нөгөөг хүлээнэ

24. Lec 9.249/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Гүүр давах жишээ
• Замын хэсэг бүрийг нөөц гэж үзвэл
– Машин бүр тухайн хэсгээ эзэмшинэ
– Шилжиж орж буй хэсгээ өөрийн болгох ёстой
• Гүүрний хувьд: 2 хэсгийг эзэмшинэ
– Замын хөдөлгөөн нэг удаадаа нэг чигт байна
– Гүүрэн дээр эсрэг урсгалын 2 машин нэг нэг хэсэгт уулзвал
асуудал үүснэ:
• Хэрэв нэг түгжрэл тохиолдвол: нэг машин нь ухарснаар
энэ асуудал шийдэгдэнэ (нөөцийг хүчээр суллаж буцаах)
– Хэд хэдэн машин ухрах хэрэгтэй байж магадгүй
• Гачигдал гарах боломжтой
– Зүүн тийш явж байгаа урсгал хурдан байх  хэн ч баруун
тийш яваагүй байна

25. Lec 9.259/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Галт тэрэгний жишээ (Нүхтэй сүлжээ)
• Тойрог хамаарал (Түгжрэл!)
– Галт тэрэг (г.т) бүр баруун тийшээ эргэхийг хүснэ
– Өөр г.т ээр блоклогдсон байна
– Олон процессортой сүлжээнд үүнтэй яг адил асуудал
үүсдэг
• Шийдэл? Тор нь 4 зүгт чиглэсэн байна гэж төсөөл
– Сувгуудын хүчээр эрэмбэлье (зам)
» Дүрэм: Эхлээд зүүн баруун, дараа нь хойшоо урагшаа
– “Хэмжээсийг эрэмбэлэх” буюу (X ба Y) гэж нэрлэнэ

26. Lec 9.269/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Хооллож байгаа хуульчдын бодлого
• 5 савх/5 хуульч (маш хямд ресторан)
– Бүх юм үнэгүй: Хуульч боломжтой бол аль нэгийг нь авна
– Идэхийн тулд 2 савх хэрэгтэй
• Яг нэг дор бүгдийг нь авбал юу болох вэ?
– Түгжрэл!
• Түгжрэлийг хэрхэн шийдэх вэ?
– Тэдний нэг нь савхаа тавих!
– Эцэст нь хүн бүр идэх боломжтой болно
• Түгжрэлээс хэрхэн урьдчилан сэргийлэх вэ?
– Нэг ч хуульч хос савхтай болоогүй байхад сүүлийн савхыг
бүү ав

27. Lec 9.279/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Түгжрэлийн 4 шаардлага
• Солбилцол
– Нөөцийг нэг хугацаанд нэг л хуулбар ашиглаж чадна.
• Эзэмшээд хүлээх
– Хуулбар нь хамгийн багадаа нэг нөөцийг эзэмшиж байгаа
бөгөөд өөр хуулбарын эзэмшсэн бас нэг нөөцийг хүлээнэ
• Хүчээр суллахгүй байх
– Нөөцийг эзэмшиж байгаа хуулбар нь хэрэглэж дуусаад сайн
дураараа чөлөөлөх үед л нөөц суларна
• Тойрон хүлээх
– Тойрон хүлээж байгаа хуулбаруудын {T1, …, Tn} гэсэн
олонлог байна
» T1 is waiting for a resource that is held by T2
» T2 is waiting for a resource that is held by T3
» …
» Tn is waiting for a resource that is held by T1

28. Lec 9.289/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Symbols
Нөөц хуваарилалтын граф
• Системийн загвар
– Хуулбаруудын олонлог T1, T2, . . ., Tn
– Нөөцийн төрлүүд R1, R2, . . ., Rm
CPU cycles, memory space, I/O devices
– Ri төрлийн нөөцөөс Wi ширхэг байгаа.
– Хуулбар бүр нь нөөцийг дараах байдлаар хэрэглэнэ:
» Request() / Use() / Release()
• Нөөц хуваарилалтын граф:
– V нь хоёр хэсгээс тогтоно:
» T = {T1, T2, …, Tn}, Систем дэх хуулбарын олонлог.
» R = {R1, R2, …, Rm}, Систем дэх нөөцийн төрлүүдийн олонлог
– Хүсэлтийн ирмэг – чиглэлт ирмэг T1  Rj
– Олголтын ирмэг – чиглэлт ирмэг Rj  Ti
R1
R2
T1 T2

29. Lec 9.299/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Нөөцийн хуваарилалтын графын жишээ
T1 T2 T3
R1 R2
R3
R4
Simple Resource
Allocation Graph
T1 T2 T3
R1 R2
R3
R4
Allocation Graph
With Deadlock
T1
T2
T3
R2
R1
T4
Allocation Graph
With Cycle, but
No Deadlock
• Эргэн санах:
– Хүсэлтийн ирмэг – чиглэлт ирмэг T1  Rj
– Олголтын ирмэг – чиглэлт ирмэг Rj  Ti

30. Lec 9.309/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Түгжрэлийг боловсруулах аргууд
• Систем түгжрэлд орж болно дараа нь сэргээнэ
– Түгжрэлийг илрүүлэх алгоритм шаардлагатай
– Нөөцийг хүчээр суллах болон програмыг хүчээр дуусгах
техник
• Систем хэзээ ч түгжрэлд орохгүй байхыг
баталгаажуулах
– Бүх цоожны эзэмшилтийг хянах шаардлагатай
– Түгжрэлд хүргэж болох цоожнуудаас татгалзах
• Системд хэзээ ч түгжрэл гардаггүй гэж үзээд асуудлыг
мартах
– Үүнийг ихэнх үйлдлийн системд ашигладаг. Ж нь: UNIX

31. Lec 9.319/29/10 Kubiatowicz CS162 ©UCB Fall 2010
T1
T2
T3
R2
R1
T4
Түгжрэлийг илрүүлэх алгоритм
• Зөвхөн нэг төрлийн нөөц  Цикл хайх
• Түгжрэлийг илрүүлэх ерөнхий алгоритм
– [X] нь m урттай сөрөг биш тоон вектор (нөөцийн төрөл
бүрийн тоо хэмжээ):
[FreeResources]: Нөөцийн төрөл бүрийн чөлөөтэй байгаа
хэмжээ
[RequestX]: X хуулбарын хүссэн хэмжээ
[AllocX]: X хуулбарыг эзэмшсэн хэмжээ
– Програмууд өөрсдөө дуусах эсэхийг шалгах
[Avail] = [FreeResources]
Add all nodes to UNFINISHED
do {
done = true
Foreach node in UNFINISHED {
if ([Requestnode] <= [Avail]) {
remove node from UNFINISHED
[Avail] = [Avail] + [Allocnode]
done = false
}
}
} until(done)
– UNFINISHED дотор зангилаа үүсвэл  Түгжирсэн

32. Lec 9.329/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Түгжрэлийг илэрүүлэхэд юу хийх вэ?
• Хуулбарыг таслах, нөөцийг суллах
– Гүүрний жишээ, Годзила машиныг замаас гаргаж гол руу
хаяна. Түгжрэлийг шийдэж чадсан!
– Хооллож буй нэг хуульчийг буудах
– Гэвч энэ нь үргэлж боломжтой биш – Солбилцолыг эзэмшиж
байгаа хуулбарыг устгах нь дэлхийг тогтворгүй болгоно
• Хуулбарыг устгалгүйгээр нөөцийг хүчээр суллах
– Хуулбараас нөөцийг түр зуур салгах
– Тооцооллын утгатай таарахгүй байж магадгүй
• Түгжигдсэн хуулбарыг ухраах үйлдэл
– Удирдлаганыхаа буцаах товчийг дарах
– Гүүрний жишээ, нэг машин ухраах (бусад машинуудыг ч
ухрааж болно)
– Өгөгдлийн сангийн нийтлэг технологи
– Дахиад өмнөхтэй ижил байдлаар ажилуулбал дахин түгжрэлд
орж магадгүй
• Маш олон ҮС-үүд өөр боломжийг сонгодог

33. Lec 9.339/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Дүгнэлт
• Төслийн хамтрагчтай ажиллах зөвлөгөөнд
– Эрт эхлэх, байнга уулзах
– Сайн зохион байгуулалттай төлөвлөгөө, бүх зүйлээ баримтжуулах,
зөв багаж хэрэгсэл, шалгах төлөвлөгөө гаргах
– (Oh, эцсийн хугацаан дээр 2 жил нэмэгдэх!)
• Starvation болон Түгжрэл
– Starvation: хуулбарыг тодорхойгүй хугацаагаар хүлээнэ
– Түгжрэл: Нөөцийг цикэллэг хүлээнэ
• Түгжрэлийн 4 нөхцөл
– Солбилцол
» Only one thread at a time can use a resource
– Эзэмших/барьж авах/ болон хүлээх
» Хамгийн багадаа 1 нөөцийг эзэмшиж шугам нь нэмэлт
нөөцүүдийг эзэмшиж буй бусад шугамыг хүлээнэ
– No preemption
» Нөөцүүдийг эзэмшиж буй хуулбарууд тэднийг сайн дураар
гаргана
– Цикэллэг хүлээх
» Цикэллэг хүлээж буй нөөцийн бүрдэл set {T1, …, Tn}

34. Lec 9.349/29/10 Kubiatowicz CS162 ©UCB Fall 2010
Дүгнэлт (2)
• Түгжрэлийг хаяглах арга техник
– Систем нь түгжрэлд нэвтрэх болон дахин сэргээхэд
зөвшөөрөгддөг
– Систем нь хэзээ ч түгжрэлд нэвтрэхгүй гэдгийг батлах
– Асуудлыг үл тоон deadlocks хэзээ ч тохиолдохгүй болохыг
үзүүлэх
• Түгжрэлийг илрүүлэх
– График нь ахиц дэвшил гаргаж байгаа эсэхийг үнэлэх
оролдлого юм
• Дараагийн удаа: Түгжрэлээс урьдчилан сэргийлэх
– Хувиарлалт бүр нь түгжрэлд хүргэх боломжтой гэдгийг
ойлгох
– Банкирын алгоритм нь энэ бүгдийг үнэлэх нэг арга юм