기본 콘텐츠로 건너뛰기

공유메모리에 40바이트 읽고 쓰는데 얼마나 충돌날까?

가끔씩 공유메모리에 있는 자료를 n개 프로세스/쓰레드가 읽고 쓰기 위해 접근할 때, 정말 충돌이 나긴할까? 물론 이론은 반드시 나긴 나는데, 이론은 이론이고... 임계영역이 I/O wait이 안 일어날 정도로 짧은 구간이더라도 충돌이 날까?

결론은 충돌난다. ㅡ_-) 덴장... 이래서 잠금장치가 여러개 있는 것이지...


아래 소스를 대충 컴파일해서 돌려보고 Ctrl+C를 눌러보면...

#include <sys/ipc.h>
#include <sys/shm.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <errno.h>
#include <sys/types.h>
#include <signal.h>

enum
{
    SHM_STR_LEN = 32
};

typedef struct str_t
{
    int len;
    char buf[SHM_STR_LEN+1];
} str_t;

volatile size_t g_total_count(0);
volatile size_t g_crash_count(0);

int g_shmfd(-1);
str_t* g_buf(NULL);

//        make random string...
void
makeRandStr(str_t& buf)
{
    memset(&buf, 0x00, sizeof(buf));

    int i, max(rand()%SHM_STR_LEN);
    for ( i = 0; i < max; i++ )
    {
        buf.buf[i] = (rand()%10) + '0';
    }

    buf.len = max;
    buf.buf[SHM_STR_LEN] = 0x00;
}

//        check str_t structure...
bool
chkBuffer(const str_t& buf)
{
    ++ g_total_count;

    int reallen(strlen(buf.buf));

    bool res(reallen == buf.len);
    if ( res )
    {
        //printf("success!\n");
        return true;
    }

    //printf("crash! len=%d real=%d\nbuf=%s\n",
    //    buf.len, reallen, buf.buf);
    ++ g_crash_count;

    return false;
}

//        signal procedure for productor.
void
productor_sigint(int)
{
    shmctl(g_shmfd, IPC_RMID, NULL);
    exit(0);
}

//        productor makes random-string and memcpy to shared-memory.
void
productor(void)
{
    signal(SIGINT, productor_sigint);
    str_t buf;
    while (true)
    {
        makeRandStr(buf);
        memcpy(g_buf, &buf, sizeof(buf));
        //printf("rand: len=%d\n", g_buf->len, g_buf->buf);
    }
}

//        signal procedure for consumer.
void
consumer_sigint(int)
{
    printf("\ntotal: %d\ncrash: %d\nfail-rate: %2.02f%%\n",
        g_total_count, g_crash_count,
        g_crash_count*100.0/g_total_count);
    shmctl(g_shmfd, IPC_RMID, NULL);
    exit(0);
}

//        consumer reads memcpy from shared-memory and check.
void
consumer(void)
{
    signal(SIGINT, consumer_sigint);
    fprintf(stderr, "Test size: %d\n", sizeof(str_t));
    fprintf(stderr, "Press Ctrl+C...");
    str_t buf;
    while (true)
    {
        memcpy(&buf, g_buf, sizeof(buf));
        chkBuffer(buf);
    }
}

//        main function. make shared-memory and fork!
int
main(int argc, char* argv[])
{
    key_t shmkey(ftok("/dev/null", 1));
    if ( -1 == shmkey )
    {
        printf("%d %s\n", __LINE__, strerror(errno));
        return 0;
    }

    g_shmfd = (shmget(shmkey, sizeof(str_t), 0700|IPC_CREAT));
    if ( -1 == g_shmfd )
    {
        printf("%d %s\n", __LINE__, strerror(errno));
        return 0;
    }

    g_buf = ((str_t*)shmat(g_shmfd, NULL, SHM_RND));
    memset(g_buf, 0x00, sizeof(str_t));

    if ( fork() )
    {
        productor();
    }
    else
    {
        consumer();
    }
}


$ g++ -o shmtest -O3 shmtest.cpp
아주 정확한 방법은 아니지만, 대충 충돌하는 것을 알 수 있을 것이다. 여러 시스템에서 돌렸을 때, 몇 퍼센트가 나올지 궁금하다. 누가 돌려주면 좋겠지만, 아쉽게도 아무도 안 돌릴 것 같다. orz OTL

참고로 아래는 CentOS 5.2에서 살포시 돌려본 결과이다.
$ ./shmtest
Test size: 40
Press Ctrl+C...
total: 186202017
crash: 985010
fail-rate: 0.53%



덧글: 혹시나 오해할까봐... MT/MP 환경에서 임계영역이 있다면 락을 걸어주는 것이 상식. 이건 그냥 가끔씩 이론은 이론이고 실제는 얼마나 충돌할까라는 맛뵈기 실험.

댓글

이 블로그의 인기 게시물

탐색기에서 OneDrive 이 2개로 보이는 문제

왜 2개가 보이는지 모르겠지만, Registry 삭제하면 됨 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace 하위 키에서 OneDrive 둘 중에 하나만 지워도 바로 반영됨. 참조:  https://answers.microsoft.com/en-us/msoffice/forum/all/duplicate-onedrives-in-file-explorer/49c935a6-287b-43a5-aed5-2dee2a1c1b22

버즈 라이브 배터리 교체

나는 버즈 라이브(SM-R180)가 좋은데, 평가가 별루였는지, 해당 스타일로 버즈를 더 이상 만들지 않고 있다. 아무튼, 오래 쓴 버즈 라이브 배터리가 슬슬 맛이 가기 시작해서, 블로그 를 참조하면서 분해 및 교체를 하였다. (진짜 쉬움) 요로코롬 위아래를 살짝 눌러주면 뚜껑이 벌어진다. 안쪽 플라스틱은 오른쪽은 분홍색, 왼쪽은 회색이다. 리본 케이블 살짝 들어내고, 기판을 떼어내면, 작은 나사가 있다. 나사를 풀고, 플라스틱을 걷어내면, 검은 양면 테이프로 고정된 CR1254 배터리가 보인다. 잘 쑤셔서(?) 꺼낸다. 새로운 CR1254 배터리를 넣는다. 음극이 아래로 가도록 하고, 분해의 역순으로 조립하면 된다. 조립할 때, 아까 풀었던 나사는 잊지 말고 꼭 조여준다. (까먹고 조립해서 다시 뜯고 조립함) 충전도 잘 되고, 소리도 잘 나는거 보면, 조립도 잘 된 것 같다. 이렇게 버즈 라이브의 수명을 강제로 늘렸다. 나중에 본체 배터리도 갈아야겠다.