1-ая часть статьи, "протестированная" в "узком" кругу, побудила сразу написать 2-ую часть статьи, которая будет состоять из "пояснений", а не обзоров других задач по многопоточности, как я планировал сначала...
Итак. В чем же проблема, связанная с многопоточностью.
1) Любой объект, у которого есть внутренние переменные, потенциально может хранить состояние данного объекта.
2) Если объект может сохранять свое состояние, то тогда он потенциально "потокоуязвим". - Представим объект Муж. Который принес зарплату. И у которого, незаметно для него, вынимает часть этих денег - объект Жена. Объект Муж утром пошел за покупками, а денег то - уже нет...
3) Именно поэтому функциональный язык программирования F# и "отлично подходит" для работы с многопоточностью - там нет постоянных объектов с внутренними переменными в них - есть только методы (содержащие локальные переменные "на стеке"). Нет сохраняемых данных - нет и проблем с синхронизаций. Вообще я почти не знаю F#, но уверен, что основное "преимущество" его, в вопросах многопоточности - именно это. - Но, согласитесь, что это - извращение в самом прямом смысле этого слова. - Они бы еще от компьютеров отказались, не только от классов, лишь бы "не было проблем с многопоточностью". :)
Решение проблемы.
1) Я предлагаю - не "барахтаться" в терминах "вот у нас есть функция, она, де, изменит данные, состояние объекта". - Я предлагаю не хранить деньги в карманах объекта Муж, а создать НАДО ВСЕМ ЭТИМ (с делегированием полномочий) объект СемейныйСовет. Который и будет давать добро или отказывать - на те или иные финансовые операции в семье.
2) В объекте СемейныйСовет будут свои внутренние данные (локальная база данных, образно говоря). Которая будет в поддержку "системе принятия решения".
3) "Фишка" в том, что у нас уже НЕТ разделяемых данных (карманов объекта Муж). - Объект СемейныйСовет накапливают всю информацию о текущих финансовых операциях и сам все решает - на что, куда и как. Именно в объекте СемейныйСовет ЕСТЬ все данные, необходимые для принятия решения (но не сами деньги).
4) СемейныйСовет - действует по "событийной" модели - дал добро на покупку пиццы, или отклонил покупку мороженого.
5) Еще раз. Потоки САМИ НЕ МОГУТ просто вот так брать данные из РАЗДЕЛЯЕМЫХ между несколькими потоками данных. Они сначала должны получить "добро". При ЗАПРОСЕ на ИЗМЕНЕНИЕ разделяемых данных - управляющий объект ДОЛЖЕН УЧЕСТЬ общую ситуацию в системе. А потоки - должны быть готовы, что может быть добро, а может быть и отказ (с соотв. обработкой таких ситуаций). Или же управляющий объект - ПОДСКАЖЕТ - что же делать. Вы видите, что мы разделяем, декомпозируем сложность. Управляющему объекту, в этом месте - мы дадим бизнес-правила, как же он должен поступать, как оценивать ситуацию.
0 коммент.:
Отправить комментарий