Здравствуйте, Кодт, Вы писали:

Спасибо за развёрнутый и полный ответ
Есть пища для размышлений. Как определюсь с концепцией — выложу описание

Alu:

СМ>>Это субъективные недостатки, а есть объективные?

Alu>Отсутствие ОО подхода для меня есть объективный минус.

Хорошо сказано

Интересно, где в этом IRunable ОО подход используется? По-моему, это всего лишь уродливый костыль для запуска потока. Поточная функция Run — это деталь реализации, и ей нечего делать в пользовательском интерфейсе объекта. А если внутренней реализации объекта нужно выполнить какую-то функцию (с передачей в неё всех необходимых данных) в отдельном потоке, то это можно сделать через нормальный функциональный объект — функтор (именно функторы в C++ служат для упаковки функций и данных в одно целое). Абстракция Callable, основанная на статическом полиморфизме, более гибкая, чем IRunable, т.к. не вынуждает пользователя наследоваться о каких-то классов и позволяет паковать функциональные объекты из составляющих прямо сходу (а-ля boost::bind).

Здравствуйте, <Аноним>, Вы писали:

А>Тому кто владеет объектом достаточно знать семантиру работы именно с объектом. А внутренними ресурсами которыми пользуется объект — память, файлы, сетевые подключения _и_ потоки — про них оставьте заботиться самому объекту.

Но мы же обсуждаем не клиентский объект, а некую сущность — представителя потока.
В минимальном виде это тупо хэндл. Минимальный вид не очень устраивает, потому что встаёт вопрос, как минимум, о передаче в поток чего-то более сложного, чем void*.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, <Аноним>, Вы писали:

А>>Тому кто владеет объектом достаточно знать семантиру работы именно с объектом. А внутренними ресурсами которыми пользуется объект — память, файлы, сетевые подключения _и_ потоки — про них оставьте заботиться самому объекту.

К>Но мы же обсуждаем не клиентский объект, а некую сущность — представителя потока.
К>В минимальном виде это тупо хэндл. Минимальный вид не очень устраивает, потому что встаёт вопрос, как минимум, о передаче в поток чего-то более сложного, чем void*.
Не надо все усложнять. Поток — это всего лишь асинхронный метод объекта, который не принимает параметров. Не надо плодить лишних зависимостей и сущностей.

Здравствуйте, Аноним, Вы писали:

А>Не надо все усложнять. Поток — это всего лишь асинхронный метод объекта, который не принимает параметров. Не надо плодить лишних зависимостей и сущностей.

Время жизни объекта и потока как собираешься согласовывать? Без дополнительных зависимостей и сущностей.

А>>Не надо все усложнять. Поток — это всего лишь асинхронный метод объекта, который не принимает параметров. Не надо плодить лишних зависимостей и сущностей.
К>Время жизни объекта и потока как собираешься согласовывать? Без дополнительных зависимостей и сущностей.
Я уже надцать раз повторял — объект прежде чем издохнуть _ждет_ поток который он же породил. Опционально ставит флажок типа "пора дохнуть" чтоб долго не ждать.
Никаких "рандеву" не надо. Поток исполняет метод объекта без параметров. Объект ждет завершения потока перед своим издыханием. Зачем здесь пользователю объекта знать про поток? Зачем потоку контролировать время жизни объекта? Пользователь объекта контролирует время жизни объекта, объект контролирует время жизни потока. Исключительно односторонняя линейная зависимость, безо всяких ОС. Как и должно быть в идеале в грамотной архитектуре приложения.

Здравствуйте, Николай Ивченков, Вы писали:

НИ>По-моему, это всего лишь уродливый костыль для запуска потока.

Этот "уродливый костыль" успешно используется в ряде библиотек/языков Примеры я приводил выше. Он прост, прозрачен и удобен. Не требует никаких вспомогательных средств. Что и требуется. Статический полиморфизм конечно привнесёт больше гибкости, но плата за это — увеличивается сложность разработки и сложность использования.

Здравствуйте, Аноним, Вы писали:

А>Я уже надцать раз повторял — объект прежде чем издохнуть _ждет_ поток который он же породил. Опционально ставит флажок типа "пора дохнуть" чтоб долго не ждать.
Это породит блокировки создоющего потока,что выглядит как-то неэффективно. "Пора дохнуть" ненадёжный вариант, т.к. его реализация ложится на пользователя.

А>>Я уже надцать раз повторял — объект прежде чем издохнуть _ждет_ поток который он же породил. Опционально ставит флажок типа "пора дохнуть" чтоб долго не ждать.
Alu>Это породит блокировки создоющего потока,что выглядит как-то неэффективно.
Не породит при грамотном дизайне

Alu>"Пора дохнуть" ненадёжный вариант, т.к. его реализация ложится на пользователя.
Аксиома многопоточного программирования №..: Поток умереть может только по своей воле.

Alu:

Alu>Этот "уродливый костыль" успешно используется в ряде библиотек/языков

В Boost.Thread от него отказались в пользу функциональных объектов, в Thread support library нового стандарта C++ — тоже.

Alu>Он прост, прозрачен

С точки зрения того, кто реализует библиотеку для работы с потоками, — да. Но для пользователя библиотеки её внутренности не особо-то важны, IMHO.

Alu>Не требует никаких вспомогательных средств. Что и требуется.

Жёсткие какие-то требования, однако.

Alu>Статический полиморфизм конечно привнесёт больше гибкости, но плата за это — увеличивается сложность разработки и сложность использования.

Где там сложность использования?

ononim:

Alu>>"Пора дохнуть" ненадёжный вариант, т.к. его реализация ложится на пользователя.
O>Аксиома многопоточного программирования №..: Поток умереть может только по своей воле.

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

если не разрешать создавать в стеке объекты thread, то почему бы в твоем примере функцию Start не сделать запускаемой в потоке с параметром
указателем на объект? или я вопрос не понял?
аналог:

struct iThread
{
     void run()
     {
          <start-thread-proc>( &iThread::start, this );
     }

protected:
     static void start(iThread* src) 
     {   
         std::auto_ptr<iWork> me( src );
         me->do_run();         
     } 

     virtual void do_run() = 0;
};

struct Thread : iThread
{
   do_run(){...}
};

Thread* thread = new Thread();
thread->run();

Alu>>"Пора дохнуть" ненадёжный вариант, т.к. его реализация ложится на пользователя.
O>Аксиома многопоточного программирования №..: Поток умереть может только по своей воле.

Неправда, если подсистема с пулом потоков предусматривает возможность ее (подсистемы) отключение пользователем, то
"пора дохнуть" единственный вариант.

Alu>>>"Пора дохнуть" ненадёжный вариант, т.к. его реализация ложится на пользователя.
O>>Аксиома многопоточного программирования №..: Поток умереть может только по своей воле.
НИ>Скорее, только в "удобный" для него момент. Порой бывает неприятно иметь дело с функцией, выполнение которой не может быть корректно остановлено в течение небольшого промежутка времени по требованию извне.
Если есть необходимость в TerminateThread — перепишите программу чтобы таковой необходимости не было. Никаких исключений. Если не можете переписать функцию, или "забить" на висящий в процессе поток — вынесите ее в отдельный процесс.

ononim:

O>Если не можете переписать функцию, или "забить" на висящий в процессе поток — вынесите ее в отдельный процесс.

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

dad>если не разрешать создавать в стеке объекты thread, то почему бы в твоем примере функцию Start не сделать запускаемой в потоке с параметром
dad>указателем на объект? или я вопрос не понял?
тут http://rsdn.ru/forum/cpp/3517991.1.aspx

Автор:
Дата: 27.08.09

так и сделано


Alu>>>"Пора дохнуть" ненадёжный вариант, т.к. его реализация ложится на пользователя.
O>>Аксиома многопоточного программирования №..: Поток умереть может только по своей воле.
dad>Неправда, если подсистема с пулом потоков предусматривает возможность ее (подсистемы) отключение пользователем, то
dad>"пора дохнуть" единственный вариант.
Ну вы вощем-то повторили мою фразу. Владелец потока говорит потоку что пора дохнуть, и ждет пока тот издохнет. Поток видит что пора сдохнуть — и дохнет. По своей воле.

Здравствуйте, ononim, Вы писали:

O>Если есть необходимость в TerminateThread

"Пора дохнуть" и TerminateThread — не одно и тоже.

O>— перепишите программу чтобы таковой необходимости не было. Никаких исключений. Если не можете переписать функцию, или "забить" на висящий в процессе поток — вынесите ее в отдельный процесс.

1. Отдельный процесс решает проблему корректного освобождения не любых ресурсов.
2. Процессов может не быть.

Здравствуйте, Alu, Вы писали:

Alu>Добрый день.
Alu>Разрабатываю свой простой пул потоков. О существовании готовых профессиональных реализаций знаю. Цель — практически Just For Fun.

В моем случае (называемом (чисто по-колхозному) — менеджер параллельных задач) присутствует такой набор объектов (интерфейсов)
— задача
— контроллер задачи
— поток
— менеджер задач

все вещи — со своим счетчиком ссылок.

потоки — одноразовые. В том смысле, что объект потока создает системный поток только один раз. Если поток остановился, то все.

---
контроллер владеет задачей, потоком задачи и менеджером (не дает ему удаляться)

---
менеджеру дают задачу. он возвращает контроллер.

у менеджера два служебных потока
— для отложенного запуска (сам не знаю нафига я его прикрутил)
— освобождение пула ресурсов: контроллеры (у него системные хендлы всякие), потоки для выполнения задач.

---
Кроме того, поскольку все это дело работает в DLL, есть еще один потока (типа супервизор потоков). Все потоки обязаны у него регистрироваться (с увеличением счетчика ссылок). Поток супервизора создается при создании первого "рабочего" потока и останавливается когда остановится последний.

В начале своей работы он делает LoadLibrary для своей DLL, выход по FreeLibraryAndExitThread (типа как то так она называется).

---
Основная головная боль во всем этом — вопросы синхронизации старта/останова.

Да и вообще, для управления всем этим добром привлечено достаточно много кода... само добро — в районе 100K кода. Как говорится, почувствуйте разницу между CreateThread и "безопасным" управлением потоками