Ответ, как представляется, заключается в том, что вы можете предоставить boost: try_to_lock в качестве параметра для нескольких из этих блокированных областей.
например,
boost::shared_mutex mutex;
// The reader version
boost::shared_lock<boost::shared_mutex> lock(mutex, boost::try_to_lock);
if (lock){
// We have obtained a shared lock
}
// Writer version
boost::upgrade_lock<boost::shared_mutex> write_lock(mutex, boost::try_to_lock);
if (write_lock){
boost::upgrade_to_unique_lock<boost::shared_mutex> unique_lock(write_lock);
// exclusive access now obtained.
}
РЕДАКТИРОВАТЬ: я также экспериментально обнаружил, что upgrade_to_unique_lockпотерпит неудачу, если у вас нет блокировки обновления.Вы также можете сделать это:
boost::upgrade_to_unique_lock<boost::shared_mutex> unique_lock(write_lock);
if (unique_lock){
// we are the only thread in here... safe to do stuff to our shared resource
}
// If you need to downgrade then you can also call
unique_lock.release();
// And if you want to release the upgrade lock as well (since only one thread can have upgraded status at a time)
write_lock.unlock().
Примечание. Вам нужно вызвать release, а затем разблокировать, иначе вы получите исключение блокировки.Конечно, вы можете просто позволить unique_lock и write_lock выйти из области видимости, тем самым освободив блокировки, хотя я обнаружил, что иногда вы хотите освободить его раньше, и вам следует тратить на это минимальное время.