Почему то редко встречается такое сочетание. 
Обычно пишут по отдельности или многопоточных или объектно-ориентированных.
Какие принципы ООП нарушаются в многопоточных программах?
Можно ли писать многопоточные программы полностью соответствующие ООП?  

  Что? Откуда такая бредовая информация?

грубо говоря поток это упрощенный вариант процесса , в процессах никто не запрещает ООП....

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

  ООП и многопоточность как соленое и серое. Но с точки зрения С++ многопоточность усложняет написание ООП программ. Считается, что объект каждый момент времени находиться в некотором определенном состоянии, а переход объекта из одного состояния в другое осуществляется мгновенно путем отсылки ему сообщения. Состояние объекта, грубо говоря, это значение всех его полей. На практике на время вызова функции (обработка сообщения) объект находиться в некотором неопределенном состоянии (невозможно одновременно изменить состояние множества полей). Для однопоточной программы нахождение в неопределенном состоянии не проблема, поскольку пока функция не выполнилась до конца другая не может исполнятся. В многопоточной же программе объект может начать обработку сообщения (вызов функции) в тот момент когда он (объект) еще находится в неопределенном состоянии. Это и станет нарушением концепции ООП. Поэтому многопоточные ООП программы должны использовать мьютексы для того, чтобы исключить неопределенное состояние. Т.е. пока не будет произведен захват мьютекса нельзя будет менять состояние объекта. 

Alexeis, всё это верно для любой структуры данных, даже для массива. Так что ООП тут не при чём.

  Несмотря на то, что ООП и многопоточность с точки зрения теории это как серое и соленое. Т.е. понятия несвязанные, но тем не менее, на практике, в частности в реализации С++ многопоточность рушит типичный механизм изменения состояния объекта (невозможно записывать данные в поля напрямую). В тоже время как любая произвольно выбранная структура или массив не описывает состояние целиком, поэтому вообщем случае нельзя говорить о неопределенности состояния в случае простых структур данных. У меня, например, есть класс массива, который без блокировки может безопасно производить одновременно 2е операции записи в массив. Именно по той причине, что один массив это еще не состояние. Проблемы начинаются у тебя как у программиста, когда ты у себя в голове рассматриваешь массив как объект подобный объекту stl vector. Но на самом массив это лишь последовательность элементов объединенная одним именем. 
  Я могу рассматривать любую последовательность элементов как некоторое состояние массива. В этом случае, массив в любой момент времени находиться в некотором определенном состоянии. Следовательно, любые операции с ним из любых потоков также будут корректно менять его состояние. 

multikoder, они ортогональны, одно другому не мешает. темы сильно разные (разного уровня).
можно использовать совместно, можно раздельно, можно вообще не использовать))))

Alexeis, ООП и многопоточность не противопоставлены друг другу, не надо выдумывать про практику. многопоточность изменяет подход к алгоритмизации в целом (независимо от использования ООП), требует обеспечения определенных условий, но и только. модель, в которой объект одновременно занимается двумя задачами, вполне реальна. есть и не связанные с многопоточностью условия, которые мы должны соблюдать (в т.ч. используя ООП), просто они настолько привычны, что их выполнение нам кажется обычным делом. распределение памяти, например.

  Меняет ли что-то многопоточность если задача решена при помощи чистых функций? 


  Модель в которой объект занимается решением задач, а тем более 2х сразу, вообще не ООП модель. Задачи решают функции. Объект концептуально не решает задачи как таковые, он лишь реагирует на сообщения. Задача, процесс и т.д. это не  про ООП. ООП - это сообщения, события (сигналы), состояния. 
  Менеджер памяти 
Состояние №1 - 25Мб выделенной памяти, 47Мб резерва
Поток №1 --> Сообщение №1 запрос 1Мб памяти.
Поток №2 --> Сообщение №2 запрос 2Мб памяти.
Состояние №2 - 26Мб выделенной памяти, 46Мб резерва
Состояние №3 - 28Мб выделенной памяти, 44Мб резерва
  Хотя объект получил 2 сообщения одновременно, он все равно последовательно перешел сначала в состояние №2, затем в состояние №3 . Это совсем плохой пример, поскольку здесь параллельные потоки выполняются по очереди и еще медленнее чем это было бы в однопоточном режиме. 

  И я совсем не говорил, что параллельное исполнение как-то противоречит ООП концепции. Оно противоречит реализации ООП в С++ . В языке С++ для реализации ООП принято, что состояние определяется набором переменных-членов класса. Посылка сообщения реализуется через вызов функции. Синтаксис С++ не имеет языковых конструкций позволяющих указать, что группа полей должна изменять свои значения одной атомарной операцией. Параллелизм С++ ООП реализуется не проще чем на языке С , т.е. отсутствует напрочь. 

  Совсем другое дело Qt, где посылка сообщения заменяется сигналом. Если источник сигнала и слот находятся в разных потоках, то в одном из вариантов реализации сигнал формирует сообщение в очереди сообщений объекта и состояние объекта изменяется атомарно в тот момент, когда объект обработает сообщение. 

за семантику и согласованность операций класса с++ отвечает программист, и неважно, в одно- или многопоточной среде это реализуется. в с++ нет типичного механизма изменения состояния объекта, он должен быть разработан для конкретного класса.
поэтому говорить, что некий типичный механизм что-то там рушит - неверно.
ООП это действительно объекты, имеющие состояние и обменивающиеся сообщениями. а раз в концепции нет "решения задач", то разговор о свойстве решения задач, в т.ч. многопоточности, не имеет смысла. алгоритмы и их реализация не пересекаются с ООП.

многопоточность не влияет и на использование класса: работа с потоками и синхронизация скрыты внутри методов класса.


ок, реагирует на следующее сообщение, не закончив обрабатывать предыдущее. стало легче от такой формулировки?   
вот модель. представим объект, решающий систему уравнений. метод solve() меняет состояние объекта: после изменения состояния система решена. такое изменение состояния занимает значительное время. также объект умеет реагировать на сообщение estimate_time(), в качестве реакции на которое он должен вернуть значение времени, через которое система будет решена.


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

Добавлено через 5 минут и 48 секунд

Это совсем плохой пример, поскольку представляет объект как state machine. Это слишком узко. Объект это обобщение SM, а не наоборот. Реальные объекты настолько сложны, что говорить о перечне состояний не приходится. Вместо этого оперируют инвариантами.

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

В частности см:

Стандартная поддержка атомарных операций:
http://en.cppreference.com/w/cpp/atomic/atomic

Стандартные средства для поддержки многопоточного программирования:
http://en.cppreference.com/w/cpp/thread/unique_lock
http://en.cppreference.com/w/cpp/thread/mutex

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



Неправда.
Стандартные средства многопоточного программирования предлагают использовать технологию raii

Например, вот так можно обеспечить "простой потока" пока не другой поток не завершит какую то свою работу:




Поток пробудил ото сна другой поток, который выполнил:



Это лишь краткий пример автоматики, которая возможно благодаря raii, который возможен благодаря ООП.
На pure С сделать что-то подобное невозможно.



Qt умеет это так же за счет библиотек языка, а не за счет ядра языка с++, на котором он базируется.

Кютешечный мьютекс, или стандартный мьютекс - это всего лишь деталь библиотеки.




Это сообщение отредактировал(а) Lukkoye - 2.4.2014, 22:37

на С все возможно, только многословнее. raii особенно удобен в среде с исключениями, но в С нет исключений, и в этом смысле проблем меньше.
raii часто ошибочно связывают с ООП, но фактически к ООП он не относится. просто некоторые средства некоторых языков с поддержкой ООП позволяют это изящно реализовать.

  Не согласен. Каждый ЯП имеет свой набор синтаксических конструкций предназначенных для выполнения определенного круга задач. Возьмем к примеру язык С и реализуем на нем наследование.

Объект B унаследовал все из объекта А, и дополнил его новым полем b;
Теперь возьмем язык С++ .

  С точки зрения концепции ООП оба способа реализуют наследование, однако язык С++ указывает нам на то что наследование следует реализовывать именно 2м способом, а не первым. Теперь подумаем как можно сохранить состояние объекта. Инкапсуляция. Можно это сделать так.

А можно сделать это так. 

И тот и другой способ хранит состояние внутри объекта. Но в одном случае это некоторый набор байтов, который можно испортить неправильным кодом. Во втором случае состояние хранит вложенный объект, доступ к которому ограничивается специальным средством языка - модификатором protected . Модификатор protected/private - это типичный способ реализации инкапсуляции состояния объекта в С++ . Его использование подразумевает то, что поля будут описываться следом за ним. Он защищает поля от посягательства других объектов. Использование 1го варианта кода допустимо с точки зрения С++, но не типично для этого ЯП.

И 3я ситуация. Многопоточное ООП.


Сохраняется ли правильное состояние объекта А при любых операциях? Да! Защищает ли хоть как-то средство С++ состояние объекта А от одновременно полученных сообщений? Нет!
С точки зрения потокозащищенности состояния объекта данный код ничем не безопаснее чем.



  Т.е. если я захочу в иной функции написать *a->wndsize = *r; я это сделаю с одинаковым успехом, что в варианте кода С++, что в варианте С . И в обоих случаях у меня появилось лишнее поле mtx_wndsize, которое никак не определяет состояние объекта. В С++ есть средства для реализации только однопоточного ООП.

  Я бы хотел видеть 2й вариант реализации многопоточного ООП на подобии такого :


Все поля объекта хранят исключительно состояние объекта. Правильность состояния объекта гарантируют средства языка. 
 

Это сообщение отредактировал(а) Alexeis - 3.4.2014, 17:09

Alexeis, букв много но ни слова про "типичный способ изменения состояния объекта" (понятно почему - его просто нет. можно с этим не соглашаться, но тогда плиз ссылку на конструкцию, стандарт или хотя бы best practices от известного специалиста)

у меня есть класс, скажем потокобезопасная реализация std::vector. как пользователь класса я не должен думать о многопоточности. как разработчик класса я должен об этом думать, обеспечивая согласованное состояние класса. как это сделать, зависит от назначения класса и гарантий потокобезопасности, которые планируется реализовать, но вся реализация будет скрыта от пользователя.


многопоточное ООП это что-то новое)))) 
правда существует концепция актеров (Actors) - объектов, работающих асинхронно, её можно реализовать многопоточно или кооперативно. но это скорее тема для библиотечного расширения, т.к. представляет частный случай.

кстати есть std::atomic<>

Alexeis, способов выстрелить в ногу в с++ предостаточно и без многопоточности. но это уже было

Пример на С реализует агрегирование, а не наследование.


В примере нет никакой инкапсуляции. Инкапсуляция в Си делается например так:

counter.h:


counter.c:


main.c:

На сях можно написать язык, который сможет блекджек и компанию.
Но на самих сях нельзя реализовать автоматику raii.

Грубо говоря, на сях не получится сделать автоматику, которая самостоятельно освободит указатель, как только закончится его область видимости.

И если вы сами явно где нибудь не дернете free, сишный мьютекс так и не пустит поток.

У С все хорошо с полнотой языка, поэтому сделать на нем получится все. Другой вопрос, какой ценой.

Ну покажите мне, как на pure C реализовать автоматический захват ресурса - допустим, выделить память под структуру.
А потом, когда закончится время жизни указателя - автоматически освободит ресурс.

Lukkoye, если трактовать raii как паттерн, исключительно основанный на автоматическом вызове конструктора/деструктора, то да. ближе к ООП он от этого не становится

Вы путаете наследование и агрегирование.
Наследования на pure C не существует.

надо просто создать дополнительный контекст, владеющий ресурсом. с точки зрения внутренней функции use() все происходит автоматически 


Добавлено через 3 минуты и 12 секунд
естественно, можно написать более изощренный пример, позволяющий use() влиять на создание объекта. только это многословней

Это сообщение отредактировал(а) baldina - 3.4.2014, 22:56

Я не совсем понимаю фразу "трактовать raii как паттерн".

Слово "паттерн" я понимаю, как "решение", которое наиболее практичным образом решает некоторую проблему.

raii (Resource Acquisition Is Initialization) я понимаю, как идеому: получение ресурса - есть инициализация.

Суть которой - автоматический захват ресурса, и автоматическое же его освобождение.

Из этого вытекает важнейшее следствие: раии-механизмы позволяют простым способом контролировать вопросы владения и времени жизни объектов.

Собственно это главное и единственное, что вообще требуется от raii.

При этом raii - это не только автоматические вызовы конструкторов/диструкторов.

У этой концепции есть более широкая область применения.

Например: есть система и пользователи. Пользователи запрашивают ресурсы для пользования.
Система выдает ресурсы. Но ей критично контролировать время жизни ресурсов ( что бы их не грохнули без её ведома). И при этом критично знать - а они вообще ещё нужны, или их уже никто не использует.

Для этого ресурсы системы создаются и хранятся по факту внутри самой системы.
Только система знает как создать и как прибить ресурс.

Когда пользователь запрашивает ресурс - система создает его внутри себя. И заряжает шаред-указатель уже реально существующим объектом.
Так же, она устанавливает шаред-указателю функцию, которую тот автоматически вызовет, когда закончатся ссылки на него.

Таким образом, ресурсы по факту живут внутри системы, где она может гарантировать их целостность.
И ей не нужно самостоятельно пасти - использует ли их кто ещё снаружи.

Как только ресурс станет не нужным - шаред-указатель уведомляет её.
И она может, например, просто снять ресурс рабочего конвейера и перевести в зону ожидания новых запросов пользователя.
А может и пригрохать, это как разработчику захочется.


Резюмируя: идеома raii - это идея, как можно очень легко и просто контролировать вопросы владения и времени жизни объектов.

Добавлено через 1 минуту и 29 секунд


Я просил автоматику.

Меня не интересует точка зрения функции use
Меня интересует точка зрения программиста, которому нужно вручную дергать 

construct (obj);
destruct (obj);

И не дай боже этого забывать.

Это ни разу не автоматика.

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

название "raii" это идиома. raii в отношении к с++ это паттерн. в отношении к любым языкам - это концепция единственного владельца ресурса. и вот эту концепцию можно реализовать в любом языке

Это сообщение отредактировал(а) baldina - 3.4.2014, 23:22

У вас последнее предложение противоречит первому.
Кто-то вручную должен написать construct и destruct.

Это уже не автоматика. 
И если ближе к реальной практике, то весь pure C - это один сплошной низкоуровневый слой.

Для сишника - выделить память, чем то её заполнить, а потом освободить - это обычная рутинная работа.
И сишник знает - кроме него самого, никто это это за него не сделает.
И ни одна сишная программа без этого не обходится.




Вот мне не понятно: в отношении к с++, как понять "raii -это паттерн" ?

Как вариант:





Только 1) нужно придерживаться определенного соглашения и 2) при возникновении аварийной ситуации (сегфолт например) внутри body, деструктор не вызовется (насколько я понимаю).

k0rvin, awesome !
Лямбда ни Си. ЗдОрово !

Это сообщение отредактировал(а) borisbn - 4.4.2014, 10:25

Ну что ж, в таком случае есть универсальный ответ: на C можно написать компилятор C++. Исходные коды приводить не будем ввиду их объемности.   

О чем Lukkoye уже сказал здесь.

Это сообщение отредактировал(а) k0rvin - 4.4.2014, 10:42

Ага. Но вот где проходит граница между "можно реализовать на самом языке" и "нельзя реализовать на самом языке" - вопрос открытый. 

Очевидно, что если можно написать компилятор, то можно и интерпретатор, а это означает, что все те же средства принципиально возможно приделать и к программе на C. Следовательно, имеет смысл обсуждать только вопрос о том, насколько это удобно.

На самом языке - на уровне исходного текста программ, которые пишутся на этом языке


Пример:

с++2003 стандарт не поддерживает оператор decltype. В коробке с гцц идет в поставке оператор typeof, но лишь, как расширение от компилятора.
Стандартного средства не существовало.

Реализовать самодельный typeof кросскомпиляторно, который предоставлял бы полную автоматику (как decltype) было не возможно.

Но можно было реализовать дизайн, который пусть не в полной автоматике, и с целый кучей всяких ограничений, тем не менее умел бы идентифицировать тип времени компиляции:



Ну так вот, с++11 decltype - это технология новых компиляторов.
Программист может пользоваться и не геммороится о том, кто и как ему эту возможность обеспечивает.

А костыльный typeof с дикими лагами и ограничениями - это уже продукт самого программиста, которому пришлось задалбливаться на диких шаблонах и макросах, что бы обеспечить хоть какое то подобие нужного поведения.

Итого: 
с++03 не поддерживает технологию decltype , и реализовать её в полноценном виде на языке невозможно. Можно сделать лишь сильно ограниченные костыли-велосипеды.
с++11 поддерживает технологию из коробки. Программист может просто пользоваться и не париться.



Это сообщение отредактировал(а) Lukkoye - 4.4.2014, 13:42

k0rvin, отлично! 


чего тут непонятного. 

вот так и следует понимать: raii можно реализовать известным образом встроенными средствами c++ для решения проблемы управления ресурсами. собственно скелет паттерна выглядит так

что касается слов "raii это идиома", их следует понимать так: raii - это устойчивое выражение, имеющее смысл обсуждаемой технологии управления ресурсами. не следует искать смысл в словах самого выражения Resource acquisition is initialization, они условны. "идиома" - лингвистическое понятие, а не техническое.

Это сообщение отредактировал(а) baldina - 4.4.2014, 15:44

Видимо нужно: сейчас очень активно "пилят" транзакционную модель памяти, может к 17 году и допилят


GC есть в C++, но "необязательный"

Ааа... понял о чем вы.

Только вот вы слегка путаетесь в понятиях.

Раии - идеома. 
Вот "реализация идеомы" - это уже технология, которая реализована за счет компиляторов.

То, что вы показали выше  - это не пример реализация раии. Реализация раии, грубо говоря внутри компилятора.

То, что вы показали - это пример одного из возможных использований особенностей раии. 
А сам паттерн, если не ошибаюсь, называется "scope guard".

Ну да бог с ним, не суть это все буквоедство.
Я понял вашу точку зрения.

идиома
паттерн
raii

вроде бы не я путаюсь. "raii зашит в компилятор" - это забавная точка зрения. отчего тогда в программах на с++ возникают утечки ресурсов?

Добавлено через 6 минут и 56 секунд
сейчас вы будете мне рассказывать, что компилятор вставляет вызовы конструкторов и деструкторов, и они вызываются автоматически, только это семантика не raii, а конструкторов и деструкторов. с помощью которых мы можем следовать raii или наплевать на него.


Это сообщение отредактировал(а) baldina - 5.4.2014, 15:02

http://www.stroustrup.com/bs_faq2.html#finally
на викибукс:
raii
scope guard

Потому что язык с++  - это мультипарадигменный высокоуровневый ассемблер с прямым доступом к памяти.

Идеома raii в нем реализована за счет автоматических экземпляров классов - объектов, для которых конструктор и диструктор вызываются автоматически. 

Однако, язык не заставляет обязательно использовать автоматические экземпляры классов, равно как и вообще писать в оо-стиле. На этом языке вы можете писать в самых разных стилях, например: в стиле си.

Поэтому, я так отвечу на ваш вопрос: утечки в программах на с++ возникают потому, что некоторые товарищи используют низкоуровневую ручную работу и пишут суржик в стиле си, вместо того,
что бы использовать всю мощь объектно ориентированного с++ вкупе с его стандартной библиотекой.


Это сообщение отредактировал(а) Lukkoye - 6.4.2014, 13:33

1 троль + 1 провокационный вопрос = 3 страницы переливания из пустого в порожнее, местами переходящее во флейм