Polling API와 Event Bit: 깨어났다면 무엇이 남아 있나

1. 객체를 가로질러 기다릴까, 비트를 함께 기다릴까

k_poll()은 semaphore, FIFO, message queue, pipe, poll signal처럼 서로 다른 객체의 준비 조건을 한 스레드가 함께 관찰한다. 하나 이상이 준비되면 반환한다. k_event는 한 객체의 32비트 상태에 원인별 비트를 놓고, 지정한 비트 중 하나 또는 전부가 켜졌는지를 판정한다. 이름이 비슷한 k_poll_event.state는 전자의 배열 원소에 남는 알림 상태이고, k_event의 비트 값과 같은 저장소가 아니다.

근거: Polling 정의, Event 상태와 대기 정의, poll event 구조.

2. “준비”가 뜻하는 것은 객체마다 다르다

k_poll_event에는 조건의 종류, 대상 객체, 현재 state가 있다. v3.7.0에서 사용 가능한 mode는 K_POLL_MODE_NOTIFY_ONLY다. 준비를 보고도 객체가 호출자에게 넘어오지 않으므로, 데이터 전달 형식과 별개로 어떤 동작을 다시 시도해야 하는지를 먼저 정해야 한다.

근거: 객체별 실제 준비 검사, type·state 상수, notify-only와 후속 확인.

3. 알림은 예약이 아니다

k_poll()이 0을 돌려줘도 semaphore나 메시지의 소유권을 예약한 것은 아니다. 직접 take/get을 기다리던 스레드가 poller보다 먼저 객체를 얻을 수 있고, 알림을 받은 뒤 다른 소비자가 끼어들 수도 있다. 따라서 후속 획득은 K_NO_WAIT로 시도하고 실패를 정상 경쟁 결과로 다룬다.

한 번의 poll이 끝났다고 배열의 첫 원소만 보지 말자. 반환할 때 두 조건 이상이 준비될 수 있으므로 모든 state를 검사한다. 재사용 전에 각 state를 K_POLL_STATE_NOT_READY로 되돌린다. Signal에는 별도의 signaled 플래그도 있다. 다시 기다리려면 k_poll_signal_reset()으로 플래그를 지우고 poll event의 state도 초기화해야 한다.

/* sem, msgq, sig는 각각 이미 초기화되어 있다고 가정 */
struct k_poll_event watch[3];
k_poll_event_init(&watch[0], K_POLL_TYPE_SEM_AVAILABLE,
                  K_POLL_MODE_NOTIFY_ONLY, &sem);
k_poll_event_init(&watch[1], K_POLL_TYPE_MSGQ_DATA_AVAILABLE,
                  K_POLL_MODE_NOTIFY_ONLY, &msgq);
k_poll_event_init(&watch[2], K_POLL_TYPE_SIGNAL,
                  K_POLL_MODE_NOTIFY_ONLY, &sig);

for (;;) {
    int rc = k_poll(watch, 3, K_FOREVER);
    if (rc == 0) {
        if (watch[0].state & K_POLL_STATE_SEM_AVAILABLE) {
            if (k_sem_take(&sem, K_NO_WAIT) == 0) { handle_token(); }
        }
        if (watch[1].state & K_POLL_STATE_MSGQ_DATA_AVAILABLE) {
            if (k_msgq_get(&msgq, &item, K_NO_WAIT) == 0) { handle_item(&item); }
        }
        if (watch[2].state & K_POLL_STATE_SIGNALED) {
            unsigned int raised;
            int result;
            k_poll_signal_check(&sig, &raised, &result);
            if (raised) { handle_signal(result); }
            k_poll_signal_reset(&sig);
        }
    }
    /* -EINTR 같은 다른 반환도 별도 정책으로 처리 */
    for (size_t i = 0; i < 3; ++i) {
        watch[i].state = K_POLL_STATE_NOT_READY;
    }
}

위 코드는 핵심 순서를 보여 주는 발췌다. handle_*, item, 객체의 실제 선언과 오류 정책은 애플리케이션이 채운다. 여러 생산자가 같은 poll signal을 반복해서 raise하면 reset 경계의 알림이 합쳐지거나 놓일 수 있다. 발생 횟수가 필요하면 signal보다 count가 있는 semaphore나 항목을 저장하는 FIFO/msgq를 선택한다. Signal을 초기화·reset하는 소유자는 polling 스레드로 두는 것이 문서의 권장 방식이다.

근거: poll 반환·경합·state 재설정, 여러 준비 원소 검사, signal 플래그·결과·raise, 반복 reset과 신호 경쟁.

4. post, set, clear는 같은 32비트를 다르게 고친다

k_event는 이벤트 발생 횟수나 payload 큐가 아니라 켜져 있는 조건의 비트 집합이다. 예를 들어 아래는 32비트 중 낮은 네 비트만 보인 것이다. post는 OR로 더하고, set은 전체를 교체하며, clear는 지정한 비트만 내린다.

근거: mask 적용식과 다중 waiter 검사, post·set·set_masked·clear 인수.

5. any/all은 판정 조건, reset은 대기 전 초기화

k_event_wait(e, mask, false, timeout)는 mask 중 하나라도 켜지면, k_event_wait_all은 모두 켜져야 반환한다. 성공 반환값은 저장된 전체 값이 아니라 현재값 & mask다. false로 기다리면 반환 뒤에도 비트가 남는다. true는 “읽은 비트 소비”가 아니라 대기 시작 전에 객체의 모든 비트를 0으로 지우기다.

요청 mask가 0이면 v3.7.0 구현은 reset 처리보다 먼저 0을 반환한다. 따라서 이 경우 reset=true여도 저장 비트를 지우지 않는다. 위 그림과 표는 요청 mask가 0이 아닌 경우다.

대기 중 새 비트가 조건을 만족하면 해당 waiter들이 깨어나지만 비트는 자동 소모되지 않는다. 여러 스레드가 같은 객체를 기다릴 때 한 스레드의 reset=true는 다른 스레드가 보던 비트도 지울 수 있다. 이미 처리한 특정 상태만 내려야 한다면 해당 bit mask로 k_event_clear()를 명시적으로 호출하되, 다른 생산자가 같은 비트를 동시에 갱신하는 설계에서는 세대 번호나 별도 큐가 필요한지 따져야 한다.

근거: any/all 판정, 대기 전 reset·반환 mask, 만족한 waiter 깨우기, 공개 wait 계약.

6. timeout과 ISR의 선을 넘지 말자

서로 다른 결과형에 주의한다. Poll은 성공/오류를 int로 반환하고 준비 원인은 배열의 state에 둔다. Event wait는 일치한 uint32_t 비트 자체를 반환하며 0은 조건 불충족이다. ISR에서 현재 상태를 확인할 때 공개 헬퍼 k_event_test()는 내부적으로 k_event_wait(..., false, K_NO_WAIT)를 호출한다.

근거: poll의 ISR assert와 즉시 반환, poll 반환 계약, event ISR의 블로킹 제한과 0 반환, k_event_test 헬퍼, ISR의 event 전달·조회.

7. 객체의 준비와 사건의 기록을 구별하기

하나의 dispatcher가 여러 입력원을 기다리고 각 객체를 별도로 소비한다면 k_poll이 알맞다. 반대로 여러 조건의 현재 성립 여부를 한 비트 집합으로 공유하고 any/all을 판정한다면 k_event가 맞다. 같은 비트의 발생 횟수나 매 발생의 payload가 중요하다면 둘 중 어느 비트 상태만으로도 충분하지 않다. count나 queue에 실제 정보를 보관해야 한다.

디버깅 로그에는 k_poll의 반환값과 각 state, 실제 take/get 결과를 같은 시각에 남긴다. Event 쪽은 wait mask, reset 인수, 직전 저장 비트, 반환 비트, 이후 clear/post를 기록한다. “깨어났는데 일이 없다”는 현상도 이 두 시간축을 분리하면 경쟁인지 상태 초기화 실수인지 구별할 수 있다.

8. 고정 버전 근거와 이어 읽기

설명의 기준은 Zephyr 3.7.0 Polling API 문서와 3.7.0 Events 문서, 고정 commit의 poll.c, events.c, 공개 API 계약이다. 위 각 절의 좁은 링크는 실제 준비 검사와 상태 변경 위치를 가리킨다.