cppkorea / cppconcurrencyinaction Goto Github PK

View Code? Open in Web Editor NEW

75.0 27.0 10.0 44.62 MB

2015년 하반기에 진행하는 C++ Concurrency in Action 스터디 관련 자료입니다.

C++ 98.84% Shell 0.46% Python 0.70%

cppconcurrencyinaction's Introduction

C++ Concurrency in Action 스터디

2015년 하반기에 진행하는 C++ Concurrency in Action 스터디 관련 자료입니다.

날짜

토요일 오후 2시 ~ 5시

장소

토즈 양재점 (빈 공간이 없는 경우, 강남 지역으로 우선 대체하며 강남 지역에도 빈 공간이 없는 경우 홍대나 신촌 지역으로 대체합니다.)

스터디 인원 (18명)

강민구, 권도연, 김민준, 김선민, 박동하, 박준상, 손건, 손상우, 송은두, 옥찬호, 유주원, 윤석준, 이상형, 이윤재, 정은식, 조영수, 최동민, 최두선

교재

홈페이지
코드/정오표

일정

9월 19일 : 킥오프 미팅
10월 17일 : 스터디 진행 방식 논의 및 결정
10월 31일 : 내용 번역 및 정리 중간 점검, 부록 A 진행
11월 14일 : 1장 "Hello, world of concurrency in C++!" 및 2장 "Managing threads" 진행
11월 28일 : 3장 "Sharing data between threads" 진행
12월 12일 : 4장 "Synchronizing concurrent operations" 진행
12월 26일 : 휴식 (연말 + 크리스마스 연휴)
1월 9일 : 5장 "The C++ memory model and operations on atomic types" 진행
1월 23일 : 6장 "Designing lock-based concurrent data structures" 진행
1월 30일 : 7장 "Designing lock-free concurrent data structures" 진행
2월 6일 : 휴식 (구정 연휴)
2월 13일 : 8장 "Designing concurrent code" 진행
2월 27일 : 9장 "Advanced thread management" 및 10장 "Testing and debugging multithreaded applications" 진행

비용

선납금 : 3만원 (결석으로 인한 비용 처리를 위한 금액)
참가 비용 : 매 회 1만원 (토즈 대여 비용)
회계 담당 : 손건 (jen6)

회계 확인

계좌번호 : 389802-01-122101 국민은행 손건

[TBA]

스터디 진행 도우미

옥찬호 (utilForever)
윤석준 (DevStarSJ)

내용 번역 및 정리 담당

1장 + 부록 A : 옥찬호
2장 + 부록 A : 김민준
3장 : 조영수, 강민구
4장 : 박동하, 김선민
5장 : 최동민, 권도연
6장 : 이상형, 유주원
7장 : 최두선, 손상우
8장 : 송은두, 정은식
9장 : 손건, 윤석준
10장 : 박준상, 이윤재

cppconcurrencyinaction's People

Contributors

Stargazers

Watchers

Forkers

ssangwoo kernelgarden akaseon ejb-castis sarang2dan osebin soonho-tri secure-codenator yjd6808 sosflyyi

cppconcurrencyinaction's Issues

[폴더 정리]

오늘이나 내일 쯤 폴더를 정리할 예정입니다.
소스 코드와 발표 자료를 분리해서 게시할 수 있도록 분리할 생각입니다.

조건변수의 wait 동작에 대해 몇가지 테스트 해 보았습니다.

조건 변수의 wait 멤버 변수에서 pred 관련 동작이 궁금 하여서 몇가지 테스트를 하여 보았습니다.

template< class Predicate >
void wait( std::unique_lockstd::mutex& lock, Predicate pred );

Listing_C_01.cpp 에서의 큐 부분 입니다.

// Our message queue
class queue
{
    std::mutex m;
    std::condition_variable c;
    // Actual queue stores pointer to message_base
    std::queue<std::shared_ptr<message_base> > q;
    public:
    template<typename T>
        void push(T const& msg)
        {
            std::lock_guard<std::mutex> lk(m);
            // Wrap posted message and store pointer
            q.push(std::make_shared<wrapped_message<T> >(msg));
            c.notify_all();
        }

    std::shared_ptr<message_base> wait_and_pop()
    {
        std::unique_lock<std::mutex> lk(m);
        // Block until queue isn't empty
        c.wait(lk,[&]{return !q.empty();});
        auto res=q.front();
        q.pop();
        return res;
    }
};  // class queue

테스트 코드

int main( void )
{
    messaging::queue              sQueue;
    std::string                   sPushString( "1234" );
    std::shared_ptr<messaging::message_base>  sPopString;

    sQueue.push( sPushString );
    sPopString = sQueue.wait_and_pop();

    std::cout << ((messaging::wrapped_message<std::string>*)(sPopString.get()))->contents << std::endl;

    return 0;
}

제가 생각 하였을때는 wait 함수 내부에서 signal 를 받고 pred 함수의 반환이 true 가 되면 wait 의 block 을 풀어줄것이라고 생각하였는데 실제로는 wait 함수 들어 가면서 pred 함수를 확인해보고 시그널을 대기여부를 판단하는것 같습니다.

그리고 push 함수 안에 실재 데이터 q.push 부분을 지워 주면 signal 이 발생하더라도 wait 함수의 block 은 풀리지 않습니다.

또한 pred 조건을 만족 시키고 signal 을 발생시키지 않으면 wait 을 block 에서 풀리지 않습니다.

// 바로 위 테스트 코드 입니다.
// pred 조건을 만족 시키고 signal 을 발생시키지 않으면 wait 을 block 에서 풀리지 않습니다
void t1( messaging::queue   * aQueue )
{
    std::string                   sPushString( "1234" );

    while( gContinue == 1 )
    {
    }

    sleep( 5 );

    std::cout << "Push : " << sPushString << std::endl;

    aQueue->push( sPushString );

}

void t2( messaging::queue   * aQueue )
{
    std::shared_ptr<messaging::message_base>  sPopString;

    gContinue = 1;

    std::cout << "wait Pop" << std::endl;

    sPopString = aQueue->wait_and_pop();

    std::cout << ((messaging::wrapped_message<std::string>*)(sPopString.get()))->contents << std::endl;
}

int main( void )
{
    messaging::queue              sQueue;
    gContinue = 0;

    std::thread thread1( t1, &sQueue );
    std::thread thread2( t2, &sQueue );

    thread1.join();
    thread2.join();


    return 0;
}

그래서 결론은 wait 함수의 동작은 아래 정도로 정리 할수 있을것 같습니다.

block 들어 가기전 pred 함수가 정의되어 있으면 조건을 검사 한다.
조건이 참이면 block 으로 들어가서 signal를 대기 하지 않고 wait 함수가 반환된다.
조건이 거짓이면 block 으로 들어가서 signal 를 대기 한다.
이때 pred 함수가 참이 되는 조건이 발생되어도 block 상태에서 깨어나지 않는다.
signal 이 발생하면 block 상태에서 깨어난다.

아까 luncliff 님에게 signal Lost 가 발생 할것 같다라고 말씀 드렸었는데
2번 항목때문에 signal Lost 를 발생하지 않습니다.
c++11 이전에는 2번 부분을 감안해서 코딩해 줘야 했었는데 언어 자체에서 지원해주네요..

std::lock_guard 사용 이후 std::mutex unlock

std::lock_guard() 를 사용하였을때 아래와 같이 사용하는것이 올바른 코드 작성 법 일까요?

std::mutex some_mutex;

void lockGuardTest()
{
    std::lock_guard<std::mutex> guard(some_mutex);

    some_mutex.unlock();
}

std::lock_guard() 를 사용한 이후에 std::mutex 를 unlock 이후 std::lock_guard 동작이 궁금해서 테스트 해 보았는데 이상없이 동작 하였습니다.

std::lock_guard 의 사용 이유? 사용처?

아래와 같은 이유 때문에 std::lock_guard 를 사용하는 걸까요?

소멸자에서 mutex 에 대한 unlock 이 이루어 지므로 개발자의 실수로 unlock 을 방지
선언이후에 부분에 대하여 모든 부분을 보호
unlock 코드를 넣지 않어 코드의 간결성 유지

그리고 std::lock_guard 와 std::unique_lock 이 있습니다.
std::lock_guard 는 멤버 함수가 없습니다. 그러면 std::lock_guard 는 선언 이후에 별다른 처리를 못하고 소멸자가 unlock 을 자동으로 해주는 기능만 있는거 같습니다.
그에 반해 std::unique_lock 은 멤버 함수가 존재 합니다. 여러 operation(lock, unlock) 을 수행 할수 있습니다.
그러면 std::lock _guard는 함수 단위로 lock 를 걸때 사용해야 할까요?
(java 에서 함수명에 synchronize 를 붙이는것 처럼)

참고 자료

http://en.cppreference.com/w/cpp/thread/lock_guard
http://en.cppreference.com/w/cpp/thread/unique_lock

((messaging::wrapped_message<std::string>*)(sPopString.get()))->contents