2015-02-02 3 views
4

이 하나휘발성 키워드 RAII 관용구 (C++)와 유사한 (중요한) 코드 블록에 대한 동시 액세스를 제어하는 ​​클래스를 가지고 가정

class RAIIObj : public boost::noncopyable { 
public: 
    explicit RAIIObj(LockObj& Obj) : LkObj(Obj) { Obj.Acquire(); } 
    ~RAIIObj() { try { Obj.Release(); } catch (...) {} } 
private: 
    LockObj& LkObj; 
}; 

코드와 같은 조각을 사용하여 수행 내가 필요 에 휘발성 키워드를 사용하면 최적화 된 코드가 보이지 않습니까?

예를 들어

, 나는 LKGuard 항상 존재하는지 확인하기 위해

ALockingObj LockObj; 

void AFunc() { 
    RAIIObj LKGuard(LockObj); 

    // do some MT stuff 
} 

또는

ALockingObj LockObj; 

void AFunc() { 
    volatile RAIIObj LKGuard(LockObj); 

    // do some MT stuff 
} 

를 작성해야합니까?

LKGuard는 본문의 어느 지점에서나 사용되지 않는 로컬 변수이므로 volatile 키워드를 사용하지 않으면 함수를 최적화 할 수 있습니까?

감사

+0

[RVO] (http://en.wikipedia.org/wiki/Return_value_optimization)와 같이 생성자/소멸자 쌍을 최적화 할 수있는 인스턴스가 하나 또는 두 개만 있다고 생각합니다. 그렇지 않으면 나는 그것에 대해 걱정하지 않을 것이다. –

+0

설명해 주셔서 감사합니다. 감사합니다 –

답변

6

당신이 휘발성 선언 할 필요가없는 더.하지 컴파일러는 lkobj가 최적화되지 않는 모든 것들을 수행한다는 것을 알 수 있습니다 (int lkobj;은 분명히 아무 것도하지 않습니다).

+0

시간 내 주셔서 감사합니다. 문안 인사. –

0

표준에 관한 답변은 pm100에서 제공 한 것이 맞지만 GCC 4.9가 RAII 유형을 최적화 할 수 있다는 것을 발견했습니다 (최적화 플래그 : -Os -flto).

class MutexLocker 
{ 
    chibios_rt::Mutex& mutex_; 
public: 
    MutexLocker(chibios_rt::Mutex& m) : mutex_(m) 
    { 
     mutex_.lock(); 
    } 
    ~MutexLocker() 
    { 
     mutex_.unlock(); 
    } 
}; 

이 유형은 휘발성 만들기 해결했다 문제 :

namespace impl_ 
{ 
    class MutexLockerImpl 
    { 
     chibios_rt::Mutex& mutex_; 
    public: 
     MutexLockerImpl(chibios_rt::Mutex& m) : mutex_(m) 
     { 
      mutex_.lock(); 
     } 
     ~MutexLockerImpl() 
     { 
      mutex_.unlock(); 
     } 
    }; 
} 
using MutexLocker = volatile impl_::MutexLockerImpl; 

을 따라서, 표준 그렇게 나는 것 필요로하지 않는다는 사실에도 불구하고 이것은 내가 최적화 멀리 던지는 것을 가지고 코드입니다 공격적인 최적화를 설명하기 위해 RAII 유형을 명시 적으로 선언 할 것을 제안합니다.

+0

컴파일러는'mutex_.lock()'과 연관된 잠금이 나머지 코드에 아무런 영향을 미치지 않는다는 것을 결정 했어야합니다 (즉, 코드는 잠금의 유무에 관계없이 동일하게 실행됩니다). 이것이 실제로 사실이 아니라면'lock()'함수가 제대로 구현되지 않았고 고정 될 필요가 있다는 것을 의미합니다 -이 'volatile'을 사용하여 에러를 페이퍼에 넣는 것은 좋은 해결책이 아니며 다른 곳에서도 같은 버그가 발생할 수 있습니다 너는 깨닫지 못한다. –

+0

아마도 새 질문을 [MCVE] (http://stackoverflow.com/help/mcve)와 함께 게시 할 수 있습니다. –

+0

저는 이것이 GCC 버그라고 생각합니다. 버전 4.9.3 (arm-none-eabi)이 실제로 매우 불안정하기 때문에 이것은 놀라운 일이 아닙니다. 'lock()'메소드의 구현은 다음에서 찾을 수 있습니다 : https://github.com/ChibiOS/ChibiOS/blob/stable_3.0.x/os/various/cpp_wrappers/ch.cpp#L435-L438; 이것은 단지 이것을위한 프록시입니다 : https://github.com/ChibiOS/ChibiOS/blob/stable_3.0.x/os/rt/src/chmtx.c#L139-L236. (네, 이것은 임베디드 시스템입니다). MCVE가 여기서 도움이 될 것이라는 것을 알고 있지만, 임베디드 어플리케이션을 제공하는 것은 다소 복잡합니다. –

관련 문제