Опять вопрос 


Вот такое зависает, т.к, насколько я поняла, нужна синхронизация потока с формой.
Как её сделать?
Для C++ примера не нашла, только для Делфи, но его не получается применить, изменив синтаксис...

Валерия, вы запостили в узкоспециализированном разделе. тут мало кто вообще знает что такое boost и boost::thread в частности.

1.

это лишнее. т.к. вы заставляете основной поток ждать завершения порожденного потока. т.е. из-за этого весь смысл потока теряется.
2.

оставьте тело пустым, и отпишитесь о результате.

Было 2 потока, я вначале их создаю, а потом каждому делаю join - тогда они работают парралельно, а не последовательно



Когда нажимаю на кнопку, то внизу пишет 

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


это где?  

Это сообщение отредактировал(а) boostcoder - 25.11.2010, 17:04

Event log

сделайте тело таким:

проверьте что есть вывод в консоль, и прога не виснет.

Я уже делала такое, даже в 2 потока, работало отлично и главное - парралельно (сделала в каждом потоке while(1){cout << "test\n"; Sleep(1000);} )

У меня проблема только с доступом к форме 

не надо нас оскорблять   

Валерия, мне искренне интересно чем Вас не устраивает собственный враппер VCL - TThread? тем более маловероятен тот факт, что boost::thread будет адекватнее TThread при работе с формами без дополнительных костылей.

  Могу рассказать как это делает VCL-ский TThread. Он ждет до тех пор пока главный поток не войдет во внутренний обработчик OnIdle . Делается это следующим образом. Дополнительный поток пытается захватить сразу 2е критические секции. 1я свободна всегда (сигнальная). Захват ее будет для главного потока признаком того что имеются ожидающие исполнения действия. Но второй поток должен заблокироваться ожидая разрешения главного потока (синхронизирующая). Когда у главного потока нет работы, то он периодически заглядывает в свой OnIdle и проверят не занимал ли кто сигнальную критическую секцию. Если она занята, то он освобождает синхронизирующую критическую секцию на которой заблокирован дополнительный поток, а сам пытается занять сигнальную(которая занята). Т.о. главный поток засыпает ожидая, пока дополнительный не закончит свои действия и не освободит сигнальную критическую секцию. Дополнительный поток закончил работу, теперь главный проснулся и должен снова заблокировать синхронизирующую критическую секцию, но не раньше чем отпустит сигнальную (думаю понятно почему).
  Внутренний обработчик OnIdle нам не доступен, но зато доступен Application.OnIdle, который вызывается примерно с такой же частотой как и внутренний.  

Почему там где я юзаю стандартный компонент - мне советуют юзать boost.
А там где разобралась с бустом - советуют юзать стандартное?   

если есть родной враппер, то лучше использовать его, если нет - прикручивает стороннюю библу. тем паче речь о потоках и гуе. 

  Неправда! boost::regex более стандартный чем кустарный TRegExp . Просто VCL удобнее всего использовать вместе с классами VCL чем с любыми другими. 

Пытался срубить дерево, топором. Мне сказали - возьми бензопилу и не мучайся. Взял, спилил за 5 минут, и получил спиленным деревом по башке   
Вывод - какая сволочь посоветовала брать бензопилу!?

Нужны thread'ы - или используйте boost::thread и не лезьте из них в VCL (ну не предназначен VCL для такой работы), или используйте то, что предназначенно (TThread)

Ну можно лазить с помощью ::PostMessage или ::SendMessage и тогда будет все равно какие враперы использовать

чет смахивает на аццкий костыль.