всем привет.

следующий код:

выводит в консоль одинаковые ID`ы.

но, к примеру, такой код, выводит разные:


второй вариант мне кажется правильным.

или я чего-то недопонимаю?

спасибо.

Добавлено через 3 минуты и 48 секунд
этот вариант тоже выводит разные ID`ы.


так какой вариант правильный?

boost:

не получается ли тут default-constructed id?

я так понял, что boost::this_thread::get_id() возвращает идентификатор контекста в котором объект boost::thread создан.
вот только как получить ID контекста в котором выполняется код(а не в котором живет объект boost::thread)?

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

та вот и не понятно...

я не прав, не оттуда цитата...

то ж другое дело

boostcoder

boost::thread в отличии от POSIX использует не системные ID-шники а свои внутренние. 
У меня этот код выводит разные значения, но в принципе boost оставляет за собой право использовать заново ID уже завершенных потоков. Попробуй перенести вывод ID основого потока до join()-а, в таком случае оба потока на момент вывода существуют и обязаны быть уникальными.

ну верно, как описано в boost, единственное назначение id отличить исполняемые потоки. а handler() к тому моменту завершен

  
У типа thread::id слишком жесткие требования, чтобы можно было сделать его портируемым используая системные идентификаторы.  

т.е., я так понимаю, что на каждой платформе принцип получения этих ID`ов тоже разный?

Добавлено через 33 секунды
всем спасибо. вопрос закрыт.

скажите, кому-либо, когда-либо, приходилось использовать ID`ы потоков для чего-то?

нет, так сделано именно для того, чтобы не зависеть от платформы. В POSIX нет никаких гарантий по поводу типа pthread_t, это сильно мешает реализации вывода идентификаторов, сравнению и так далее, потому в boost своя реализация, насколько я знаю это на самом деле обычный адрес.


Для логирования и отладки. Еще приходилось в WinAPI для работы с конкретным потоком, но в boost этот ID ничего не обозначает, он существует лишь для идентификации работающих потоков. Из применений можно например подсчитать хэш для thread::id и таким образом имитировать thread local storage в глобальном массиве. Можно найти применения при желании.

Это сообщение отредактировал(а) azesmcar - 28.1.2011, 19:38

в общем понял. кроме как для отладки, он никакой ценности не представляет.

еще раз спасибо.

Ну почему же, я привел пример.


Да вообще в любой задаче, где нужна идентификация потоков. Можно использовать в реализацию work stealing thread pool-а, так-как там необходим TLS, но также нужна возможность получения доступа к локальным данным другого потока при необходимости. В таком случае глобальный массив с одним элементом для каждого потока ялвяется хорошим решением, никакой синхронизации (во всяком случае со стороны программиста, процессору тут наверняка придеться потрудиться). Хотя в данном случае было бы легче передавать очередной идентификатор потоку в виде аргумента при создании вместо подсчета хэша... в общем сложно однозначно сказать, может и пригодиться.

я имел ввиду реальный опыт использования. а не возможности)

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

Есть реальный пример (с родными thred id,  а не boost'а, но суть та же)
Есть система, в которой есть главная нить, исполняющая аналог Виндового message loop'а (это не message loop, но суть та же). И есть некий класс (по сути RPC вызов, хотя не совсем RPC но сути это не меняет . В этом классе есть метод, который посылает запрос на удаленный сервер и ждет ответ (который приходит по независимому каналу). Так вот, если этот метод вызывается в потоке, отличным от главного, то он может спокойно ожидать ответа, заблокировавшись на event'е, который взведет ответ (из независимого канала). Но если вызов был в основном потоке, то блокироваться нельзя (получится deadlock, т.к. цикл обработки сообщений обрабатывает ВСЕ каналы). В таком случае метод крутит цикл обработки сообщений сам, и ждет установки того же event'а (проверяя его периодически в цикле)

Для проверки - главный поток или не главный поток использовалось сравнение thread ID

  
навеяло