草庐IT

scoped-lock

全部标签

c++ - `unique_lock`、 `scoped_lock` 和 `lock_guard` 中指定的 mutex_type 的用例是什么?

用于保护std::mutex的c++11mutexRAII类型都有一个typedef:typedefMutexmutex_type;std::lock_guard::mutex_typestd::unique_lock::mutex_typestd::scoped_lock::mutex_type这个成员typedef有什么意义?起初我认为它可以用来概括创建一个对象来移动锁(在unique_lock的情况下)例如:templatevoidfunction(SomeLockin)SomeLock::mutex_typenewMutex;//Dosomething但我无法想象它的用途。需要

c++ - _locking() 到底做了什么?

正在寻找this的答案问题我找到函数_locking().There告诉它Locksorunlocksbytesofafile(实际上我无法理解这句话的真正含义)。如果有人有使用该功能的经验,是否可以使用该功能解决第一个问题中描述的问题? 最佳答案 引用您链接的MSDN页面:int_locking(intfd,intmode,longnbytes);The_lockingfunctionlocksorunlocksnbytesbytesofthefilespecifiedbyfd.Lockingbytesinafileprevent

c++ - 在什么时候将 unique_lock 与 shared_mutex 一起使用?

通常,当使用“普通”互斥量时,您会像在remove1()中那样使用它。但是,现在有了shared_lock和unique_lock,是否应该先使用共享锁,只有在必要时才使用唯一锁?请注意,当模型不存在时,remove()可能不需要unique_lock。voidremove1(intid){std::unique_locklock(mutex_);for(autoit=models_.begin();it!=models_.end();++it)if((*it)->getId()==id){it=models_.erase(it);return;{}voidremove2(intid)

c++ - is_lock_free() 在升级到 MacPorts gcc 7.3 后返回 false

以前,在AppleLLVM9.1.0中,128位结构上的is_lock_free()已返回true。为了获得完整的std::optional支持,我随后升级到MacPortsgcc7.3。在我第一次尝试编译时,我遇到了这个臭名昭著的showstopper链接器错误:Undefinedsymbolsforarchitecturex86_64:"___atomic_compare_exchange_16",referencedfrom:我知道我可能需要添加-latomic。使用AppleLLVM9.1.0,我不需要它,对此我有一种非常糟糕的预感。如果它是无锁的,你通常不需要链接到任何额外的

c++ - CMutex::Lock 与 CSingleLock::Lock

我被要求支持一些遗留代码,我看到了一些让我摸不着头脑的事情。在某些代码段中,我看到类实例使用CMutex实例来同步方法执行。例如classCClassA:publicCObject{public:voidDoSomething();private:CMutexm_mutex;}voidCClassA::DoSomething(){m_mutex.Lock();//...logic...m_mutex.Unlock();}在同一项目的其他地方,我发现代码正在使用CSingleLockclassCClassB:publicCObject{public:voidDoSomething();p

c++ - std::scoped_allocator_adaptor 和一个使用 std::allocator_arg_t 构造函数的类

我在这里找到了一些词http://en.cppreference.com/w/cpp/memory/scoped_allocator_adaptor/constructifstd::uses_allocator::value==true(thetypeTusesallocators,e.g.itisacontainer)andifstd::is_constructible::value==true,thencallsstd::allocator_traits::construct(OUTERMOST(*this),p,std::allocator_arg,inner_allocator

C++ 错误 : was not declared in this scope with private after public

试图修改来自thispage的代码.问题代码如下:#include#includetemplateclassconst_reverse_wrapper{public:const_reverse_wrapper(constT&cont):container_(cont){}decltype(container_.rbegin())begin()const{returncontainer_.rbegin();}decltype(container_.rend())end(){returncontainer_.rend();}private:constT&container_;};templ

c++ - 触发 COM 事件时调用 Lock()/Unlock() 的目的是什么?

ATLCOM服务器中触发事件的一段典型代码如下(从thisquestion复制并略微删减):HRESULTFire_MessageTrigger(){HRESULThr=S_OK;T*pThis=static_cast(this);intcount=m_vec.GetSize();for(inti=0;iLock();//I'maskingaboutthis...CComPtrpunkConnection=m_vec.GetAt(i);pThis->Unlock();//andthisIDispatch*pConnection=static_cast(punkConnection.p)

c++ - 为什么 std::condition_variable 采用 unique_lock 而不是 lock_guard?

这个问题在这里已经有了答案:C++11:whydoesstd::condition_variableusestd::unique_lock?(2个答案)关闭4年前。std::condition_variable使用如下:std::condition_variablecv;...std::unique_locklk(m);cv.wait(lk,[]{returnprocessed;});在我看来有一个有趣的问题。unique_lock可以延迟,它可以被交换掉。它可能有许多其他代码设计原因,不一定是错误的,它实际上没有被锁定。例如。std::unique_locklk(m,std::try

c++ - unique_lock::unlock 在 C++11 标准中未指定吗?

C++11标准将unique_lock::unlock定义为(§30.4.2.2.2,第1159页)voidunlock();Effects:pm->unlock()Postcondition:owns==falseThrows:system_errorwhenanexceptionisrequired(30.2.2).Errorconditions:—operation_not_permitted—ifonentryownsisfalse.所有其他锁定操作指定至少在两次情况下抛出异常:互斥量为NULL(抛出system_error和errc::operation_not_permit