Пример отсюда:
http://www.brainbell.com/tutorials/C++/Making_A_Resource_Thread-Safe.htm
bool dequeue(T& x) {
boost::try_mutex::scoped_try_lock lock(tryMutex_);
if (!lock.locked( ))
return(false);
else {
if (list_.empty( ))
throw "empty!";
x = list_.front( );
list_.pop_front( );
return(true);
}
}
private:
boost::try_mutex tryMutex_;
// ...
студия пишет:
error C2039: 'locked' : is not a member of 'boost::detail::try_lock_wrapper<Mutex>'
Я как-то неправильно пользуюсь try_mutex?
Здравствуйте,
Аноним, Вы писали:
O_>>Я как-то неправильно пользуюсь try_mutex?
А>Трудно заглянуть в документацию?
А>http://www.boost.org/doc/libs/1_39_0/doc/html/thread/synchronization.html#thread.synchronization.locks.scoped_try_lock
И все-таки хотелось бы увидеть пример правильного использования.
Мне нужно, чтобы если один из потоков уже работает с объектом (например находящимся в списке), то другой поток не должен ждать первого, а переходить к следующему..
O_>Мне нужно, чтобы если один из потоков уже работает с объектом (например находящимся в списке), то другой поток не должен ждать первого, а переходить к следующему..
И в чём сложности? Идём по моей ссылке, смотрим какие есть методы в описании scoped_try_lock, находим там owns_lock (по-моему, по названию и типу уже легко догадаться что делает эта функция) и не находим locked (если нету такой функции, то с чего бы твоему примеру компилироваться?). Дальше читаем: "The semantics of each constructor and member function are identical to those of boost::unique_lock<MutexType> for the same MutexType, except that the constructor that takes a single reference to a mutex will call m.try_lock() rather than m.lock()." Переходим к описанию
boost::unique_lock<MutexType>, снова находим там owns_lock и его описание:
bool owns_lock() const
Returns:
true if the *this owns the lock on the Lockable object associated with *this.
Throws:
Nothing.
Если неясно что делает конструктор scoped_try_lock, то читаем описание конструктора unique_lock (в доке сказано, что он ведёт себя аналогично):
unique_lock(Lockable & m,boost::try_to_lock_t)
Effects:
Stores a reference to m. Invokes m.try_lock(), and takes ownership of the lock state if the call returns true.
Postcondition:
mutex() returns &m. If the call to try_lock() returned true, then owns_lock() returns true, otherwise owns_lock() returns false.
Throws:
Nothing.
Делаем выводы: если конструктор boost::try_mutex::scoped_try_lock захватывает владение мьютексом, то owns_lock() возвращает true, а иначе — false. Если внимательно приглядеться к другим функциям, то можно увидеть, что вместо вызова owns_lock можно использовать неявное преобразование к bool или
operator!. Что тут может быть непонятно? Я сам никогда не пользовался Boost.Thread, но причину проблемы и способ её решения нашёл за 5 минут. Чтобы напечатать и отформатировать этот пост, у меня времени ушло втрое больше.
