IMHO, не совсем.
http://blog.emptycrate.com/node/290

имелось ввиду unique_future/shared_future(ссылка), а что это там за шаблон future? я такого в boost не видел, и тем более там внизу написано что это fake.

Сообщение отредактировал DEADHUNT - 30.8.2010, 22:58

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

смотри std::future<>

это переименованный boost::thread::unique_future, точно также как в boost::scoped_ptr, а в std его назвали unique_ptr.
последнее время не использую C++0x, т.к. могут возникнуть проблемы с компиляцией под различные ОСи, и с запуском под линуксом без соответствующего stdlibc++

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

как можно сравнивать производительность объектов предназначенных для различных целей? естественно то что эти объекты эффективнее использовать для того, для чего они предназчены.

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