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

А кто сказал что они связаны? Это как раз в стиле VCL привязывать класс к потоку. Я этого избегаю.

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

ME>Это вы, батенька, очень напрасно. boost::threads элегантно и эффективно решает рутинную задачу создания потоков. boost::threads документирован и его назначение недвусмысленно. ИМХО, намного проще читать и понимать код, который оперирует стандартными высокоуровневыми сущностями, чем код, который реализует те же задачи посредством низкоуровневых API вызовов.

ME>Кроме того, использование сущностей высокого уровня позволяет инженеру сосредоточиться на problem domain, а не на том, например, в каком параметре передать указатель на ф-цию в вызове CreateThread() и не забыть проверить и правильно интерпретировать возвращаемое значение.

На проблеме позволяет сосредоточится наличие различных звеньев на этапе программинга — девелопер (coder), pj mgr и DoD. Все остальное ничего не меняет радикально и является ересью в высшем проявлении оной.

PS Я задал совершенно конкретный вопрос и получил на него совершенно конкретный ответ от Павла, за что ему большое спасибо. Вам тоже большое спасибо за то, что просвятили про boost:threads, но когда я спрашиваю "мне нужно белое", а мне говорят "вот тебе зеленое, оно лучше", это не очень приятно, поверьте, т.к. уводит собственно от темы вопроса. Тем более что мне нужно белое, а не зеленое, и я отнюдь не дальтоник. Работа в команде накладывает некоторые ограничения на используемую палитру
Всем спасибо за содействие!

Здравствуйте, MaximE,

Я сталкиваюсь часто со следующими проблемами при написании multi threaded applications:

1) Thread safe methods call
2) Stop/Start threads synchronization
3) Releasing the associated data

И не испытываю проблем по запуску функции в отдельном потоке и созданию CS and Mutecies.

Вот и вопрос, какие решения предлагает boost?

Хочу сразу отметить, что наличие в нём элементов позволяющих создать решение не означает, что это и есть решение.

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

X>Я сталкиваюсь часто со следующими проблемами при написании multi threaded applications:

X>1) Thread safe methods call
X>2) Stop/Start threads synchronization
X>3) Releasing the associated data

X>И не испытываю проблем по запуску функции в отдельном потоке и созданию CS and Mutecies.

X>Вот и вопрос, какие решения предлагает boost?

X>Хочу сразу отметить, что наличие в нём элементов позволяющих создать решение не означает, что это и есть решение.

Кстати говоря, типичная задача системы массового обслуживания — ожидание набора событий ("условий", в терминах boost).
В WinAPI это сделано, на мой взгляд, наиболее грамотно.
У меня не много опыта программирования под другими ОС, но такое впечатление, что человеческая фантазия упёрлась в POSIX, где этого не было предусмотрено.
Так, например, в vxWorks дизъюнктивное ожидание можно устроить лишь для именованых каналов. В результате, пришлось реализовать логику событий, мутексов и потоков-как-синхрообъектов на каналах. Веселуха ещё та, хотя и работает, правда, в разы медленнее, чем могло бы.

Вы скажете, нафига дизъюнктивное ожидание мутекса/семафора, а тем более — потока? Да очень даже нафига.
Если поток-хозяин хочет сообщить потоку-слуге, что пора бы завершиться — он взводит событие (хотя бы флажок) и надеется на скорую кончину слуги.
В это время слуга пытается чего-то дождаться. Вот он сперва дождётся, а потом проверит флажок, и, устыдившись, отвалит.
А в это же самое время поток-хозяин нервно курит. Он уже послал чёрную метку слуге и ждёт его кончины. Сколько он прокукует — неизвестно.
Это совершенно не увязывается с реалтаймом, где нужно гарантированное время отклика (пусть даже и не маленькое).

Выходов всего три.
Или делать нормальный API работы с синхрообъектами, умеющий ждать дизъюнктивно (конъюнктивно-то просто: выполнил подряд все ожидания — и готово).
Или мониторить состояние синхрообъектов в цикле

while(true)
{
    if(clock() > timeout) return objects_end;
    for(objects_iterator it = objects_begin; it != objects_end; ++it)
        if(ready(*it))    return it;
    sleep(epsilon);    // позволить другим потокам тоже что-то поделать в этом кванте
    // величина epsilon находится из компромисса между нужным временем отклика и загрузкой процессора
}

Или завести общий синхрообъект, и в цикле ожидать именно его.

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


К>Выходов всего три.
К>Или делать нормальный API работы с синхрообъектами, умеющий ждать дизъюнктивно (конъюнктивно-то просто: выполнил подряд все ожидания — и готово).
К>Или мониторить состояние синхрообъектов в цикле
К>

К>while(true)
К>{
К>    if(clock() > timeout) return objects_end;
К>    for(objects_iterator it = objects_begin; it != objects_end; ++it)
К>        if(ready(*it))    return it;
К>    sleep(epsilon);    // позволить другим потокам тоже что-то поделать в этом кванте
К>    // величина epsilon находится из компромисса между нужным временем отклика и загрузкой процессора
К>}
К>

К>Или завести общий синхрообъект, и в цикле ожидать именно его.

Общий, но не для всех :)
Объект, принимающий сообщения для потока:

events t1_events;

thread_main(){
while( t1_events.has_one() && dispatch( t1_events.pop() );//has_one() — блокирующий
}

main(){
t1_events.push( "It's time to die!" );

thread::join_all();
}
---------------------------------------
Но! Если в одном из алгоритмов dispatch нужно сделать ожидание:

bool dispatch( Event& e ){
...
wait_for( some_other_event );
...
}
Очевидно, что здесь ждут только одного события. В случае же когда нужно обработать выход, то видимо это должно быть исключение функции ожидания, поскольку явно алгоритм не предусматривает обработку других событий кроме ожидаемого.

Это можно сделать по-разному. Например:

bool dispatch( Event& e ){
...
t1_events.wait_for( some_other_event );
...
}

void events::wait_for( Event& e ){

while( this->has_one() ){//has_one() — блокирующий
if( this->pop() == e )
return;
dispatch( e ); // где на e_quit будет throw TerminateThread;
}
}

Xor. wrote:

> Здравствуйте, MaximE,
>
> Я сталкиваюсь часто со следующими проблемами при написании multi threaded applications:
>
> 1) Thread safe methods call
> 2) Stop/Start threads synchronization
> 3) Releasing the associated data

Не совсем понял про 2, и совсем не понял про 3.

> И не испытываю проблем по запуску функции в отдельном потоке и созданию CS and Mutecies.
>
> Вот и вопрос, какие решения предлагает boost?

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

> Хочу сразу отметить, что наличие в нём элементов позволяющих создать решение не означает, что это и есть решение.

Значит решений в бусте нет .

--
Maxim Egorushkin
MetaCommunications Engineering
http://www.meta-comm.com/engineering/

Есть интересная тема про OOP дизайт и Parallelism. Может переползём в новый тред?