Проблема змагання

МЕЗЕНХИМАЛЬНЫЕ УГЛЕВОДНЫЕ ДИСТРОФИИ

Типы углеводных дистрофий: 1\ слизистая 2\ мукополисахаридозы

1\ Слизистая дистрофия

Слизистая дистрофия связана с нарушением глюкокортикоидов и проявляется в ослизнении тканей. Суть процесса - высвобождение больших количеств муцина при распаде белково-полисахаридных комплексов и превращение межуточной ткани в слизистоподобную массу (ослизнение).

Отмечается при микседеме \снижение функции щитовидной железы (гипотиреоз) и истощение при голодании и различных заболеваниях

Значение и исход – различны. Если процесс неглубокий, локальный, то может быть полное восстановление. Однако при прогрессировании развиваются необратимые изменения и гибель межуточной ткани.

2\ Мукополисахаридозы

Это наследственная патология – проявляется в нарушении метаболизма мукополисахаридов.

Болезнь имеет несколько клинико-биохимических вариантов-

1\ мукополисахаридозы (гаргоилизм)

2\ болезнь Морфана

Мукополисахаридоз (гаргоилизм) в классическом варианте характеризуется следующими клинико-морфологическими признаками-

1\ уродливое лицо - отсюда гарголизм. Название болезни происходит от названия маленьких скульптур – уродцев (гаргоилы), которые украшают старинные здания в Париже.

2\ задержка умственного и физического развития (деменция, слабоумие)

3\ пороки сердца и патология печени и селезенки

4\ гидроцефалия

5\ низкий рост не более 130 см.

6\ тугоухость

Больные часто умирают от недостаточности сердца+пневмонии

2\ болезнь Морфана

Проявляется в нарушении метаболизма оксипролина и кислых мукополисахаридов, гиалуроновой кислоты, кислых гликозоамингликанов, что ведет к неполноценному развитию межуточной ткани за счет снижения физико-химических свойств коллагена.

Клинико-морфологические признаки болезни-

Астеническое телосложение. Высокий рост. Удлинение пальцев рук. Гипотрофия мышц. Узкая куриная грудь. Суженное лицо - птичий профиль. Артериальная гипотония. Высокие умственные способности. Причина смерти - часто пневмония, реже - сердечно-сосудистая патология.

Розглянемо на найпростішому прикладі, що може відбутися, коли потоки, які взаємодіють, разом використовуватимуть спільні дані без додаткових заходів із забезпечення синхронізації.

Уявімо, що при банківської організації системи для обслуговування кожного користувача виділяють окремий потік (чим намагаються підвищити продуктив­ність системи у разі великої кількості одночасних запитів). Припустимо, що по­міщення даних на вклад користувача зводиться до збільшення глобальної змінної total_amount. У цьому разі кожен потік під час зміни вкладу виконує такий най­простіший оператор:

total_amount = total_amount + new_amount:

Виникає запитання: чи можна дати гарантію, що внаслідок роботи із вкладом потік, який відповідає кожному користувачу, буде здатний збільшити значення total_amount на потрібну величину?

Насправді цей на перший погляд найпростіший оператор зводиться до послі­довності таких дій:

♦ отримання поточного значення total_amount із глобальної пам'яті;

♦ збільшення його на new_amount і збереження результату в глобальній пам'яті.

Розглянемо випадок, коли два користувачі А і В спільно користуються одним і тим самим рахунком. На рахунку є 100 грошових одиниць. Користувач А збира­ється покласти на рахунок 1000, користувач В у цей самий час - 100. Потік Т_А відповідає користувачу А, потік Т_А - користувачу В. Розглянемо таку послідов­ність подій (варіант 1).

1. Потік Т_А зчитує значення total_amount, рівне 100.

2. Потік Т_В зчитує значення total_amount, теж рівне 100,

3. Потік Т_А збільшує зчитане на кроці 1 значення total_amount на 1000, отримує 1100 і зберігає його у глобальній пам'яті.

4. Потік Т_В з6ільшуєзчитане на кроці 2 значення total_amount на 100, отримує 200 і теж зберігає його у глобальній пам'яті, перезаписуючи те, що зберіг потік Т_А.

У результаті внесок користувача А повністю втрачено.

Тепер розглянемо Іншу послідовність подій (варіант 2).

1. Потік Т_А зчитує total_amount, збільшує його на 1000 і записує значення 1100 у глобальну пам'ять.

2. Потік Т_В зчитує total_amount, рівний 1100, збільшує його на 100 і записує зна­чення 1200 у глобальну пам'ять.

У результаті обидва внески зареєстровані успішно.

Як бачимо, результат виконання наведеного раніше найпростішого фрагмента коду залежить від послідовності виконання потоків у системі. Це спричиняє до такого: в одній ситуації код може працювати, в іншій - ні. і передбачити появу помилки в загальному випадку неможливо. Таку ситуацію називають станом го­нок або змаганням (race condition), що є однією з найбільш важко вловлюваних помилок, з якими зіштовхуються програмісти. Вона практично не піддається тра­диційному налагодженню (оскільки нереально перебрати у налагоджувачі всі мож­ливі комбінації послідовностей виконання потоків, особливо якщо їх багато).

Спроби розв'язувати подібні проблеми викликали необхідність синхронізації потоків. Відразу ж зазначимо, що проблеми синхронізації й організації паралель­них обчислень є одними з найскладніших у практичному програмуванні. Тому розробку й особливо налагодження багатопотокових програм часто сприймають як своєрідне «мистецтво», що доступне далеко не всім програмістам.

Насправді така розробка та налагодження - це аж ніяк не мистецтво, а строга дисципліна, що підлягає одному головному принципу: оскільки для багатопото­кових програм традиційне налагодження не придатне, програміст має писати код таким чином, щоб уже на етапі розробки не залишити місця для помилок синхро­нізації. У цьому розділі ознайомимося із правилами, яких треба дотримуватися, аби створений код відповідав цьому принципу.

Розглянемо основні підходи до розв'язання проблеми змагань.

Іноді (але досить рідко) можна просто ігнорувати такі помилки. Це може мати сенс, коли нас цікавить не точна реєстрація тих або інших даних, а збір статисти­ки про них, тому окремі помилки не позначатимуться на загальному результаті Наприклад, глобальним лічильником є величина, на базі якої розраховують середню кількість запитів до системи за добу і можна проігнорувати помилки реєстрації таких запитів, що трапляються раз на кілька годин. На жаль, у більшо­сті випадків такий підхід не прийнятний.

5.2.2. Критичні секції та блокування

Поняття критичної секції

Розглянемо використання найпростішої ідеї для вирішення проблеми змагань. Неважко помітити, як джерелом нашої помилки є те, що зовні найпростіша опе­рація покладення грошей на рахунок насправді розпадається на кілька операцій, при цьому завжди залишається шанс втручання між ними якогось іншого потоку. У цьому випадку кажуть, що вихідна операція не є атомарною.

Звідси випливає, що розв'язанням проблеми змагання є перетворення фраг­мента коду, який спричиняє проблему, в атомарну операцію, тобто в таку, котра гарантовано виконуватиметься цілковито без втручання інших потоків. Такий фрагмент коду називають критичною секцією (critical section):

// початої критичної секції

total_amount = total_amount + new_amount,:

// кінець критичної секції

Тепер, коли два потоки візьмуться виконувати код критичної секції одночас­но, той з них, що почав першим, виконає весь її код цілком до того, як другий поч­не своє виконання (другий потік чекатиме, поки перший не закінчить виконання коду критичної секції). У результаті підсумку гарантовано матимемо в нашій програмі послідовність подій за варіантом 2, і змагання не відбудеться ніколи.

Розглянемо властивості, які повинна мати критична секція.

♦ Взаємного виключення (mutual exclusion): у конкретний момент часу код кри­тичної секції може виконувати тільки один потік.

♦ Прогресу: якщо кілька потоків одночасно запросили вхід у критичну секцію, один із них повинен обов'язково у неї ввійти (вони не можуть всі заблокувати один одного).

♦ Обмеженості очікування: процес, що намагається ввійти у критичну секцію, рано чи пізно обов'язково в неї ввійде.

Залишається відповісти на далеко не просте запитання: «Як нам змусити сис­тему сприймати кілька операцій як одну атомарну операцію?»

Найпростішим розв'язанням такої задачі було 6 заборонити переривання на час виконання коду критичної секції. Такий підхід, хоча й розв'язує задачу в прин­ципі, на практиці не може бути застосовуваний, оскільки внаслідок зациклення або аварії програми у критичній секції вся система може залишитися із заблоко­ваними перериваннями, а отже, у непрацездатному стані.

Дата добавления: 2014-01-11