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&lt;MutexType&gt;, снова находим там 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 минут. Чтобы напечатать и отформатировать этот пост, у меня времени ушло втрое больше.