Zephyr zbus: 같은 게시, 서로 다른 시점의 메시지

1. 채널은 항목 목록이 아니라 하나의 현재 메시지다

ZBUS_CHAN_DEFINE은 메시지 타입·초기값·validator·관찰자 목록을 지정해 채널을 만든다. 채널에는 메시지 크기만큼의 저장 영역이 하나 있고, publish는 그 영역을 갱신한 뒤 관찰자 통지를 시도한다. 여러 송신자와 수신자는 채널 이름을 통해 느슨하게 연결되지만, 이것을 모든 과거 메시지가 쌓이는 로그로 읽으면 안 된다. 세 번째 경로인 message subscriber는 기본 꺼짐인 CONFIG_ZBUS_MSG_SUBSCRIBER=y를 설정해야 쓸 수 있다.

근거: 채널의 메시지 참조·크기와 세 observer type, 채널 정의의 단일 메시지 저장 영역, message subscriber 설정 조건, 3.7.0 관찰자 설명.

2. publish는 복사와 통지를 같은 호출 안에서 진행한다

zbus_chan_pub()은 먼저 validator가 있다면 메시지를 검사한다. 채널 잠금을 얻은 뒤 송신자의 구조체를 채널 저장 영역으로 복사하고, VDED가 listener callback 호출·message subscriber 복사본 전달·subscriber 참조 통지를 관찰자 순서대로 수행한다. 그런 다음 잠금을 푼다. VDED는 별도 상주 스레드가 아니라 게시자의 실행 문맥에서 돌기 때문에, 느린 listener와 가득 찬 observer 큐는 게시 호출의 시간에 직접 영향을 준다.

반환값과 채널 내용은 별개로 확인한다. Validator가 거부하면 복사 전에 -ENOMSG가 나온다. 반면 복사 뒤 observer 통지가 실패하면 publish가 오류를 반환해도 채널의 현재 메시지는 이미 새 값일 수 있다. 재시도를 무조건 “첫 게시가 전혀 없었다”는 전제로 설계하면 중복 통지나 상태 불일치가 생길 수 있다.

근거: validator·복사·통지·해제와 반환 순서, 세 observer 통지 함수, 게시자 문맥의 VDED 설명.

3. 게시 A 다음 B가 오고, 관찰자가 늦게 읽는다면

세 관찰자가 활성화되고 통지가 모두 성공한 상태에서, 한 채널에 A를 게시하고 곧 B를 게시한 뒤 비동기 관찰자 스레드가 실행되는 경우를 보자. Subscriber 큐에는 두 번의 채널 참조가 남을 수 있지만 두 참조 모두 같은 현재 채널을 가리킨다. 두 번의 zbus_chan_read()가 모두 B를 읽을 수 있다. Message subscriber는 게시 시점의 메시지를 net_buf에 담으므로 A와 B를 각각 회수할 수 있다. Listener는 A와 B의 VDED 시점마다 직접 호출된다.

근거: callback·포인터 큐·net_buf clone, 게시 값의 버퍼 복사, 두 wait API의 회수 방식, 풀 한계와 최신값 덮어쓰기 경고.

4. read는 복사하고, claim은 잠금 수명을 호출자에게 넘긴다

zbus_chan_read()는 잠금을 얻고 채널 메시지 전체를 호출자의 버퍼에 복사한 다음 잠금을 푼다. zbus_chan_claim()은 잠금을 얻은 채 돌아와 직접 메시지나 user_data를 볼 수 있게 한다. 호출자는 반드시 zbus_chan_finish()로 잠금을 풀어야 한다. finish 자체는 관찰자에게 변경을 알리지 않는다. 직접 메시지를 수정했다면 필요한 통지는 finish 뒤 zbus_chan_notify()로 별도 수행한다.

/* state_chan은 struct state_msg 채널로 미리 정의했다고 가정 */
int rc = zbus_chan_claim(&state_chan, K_MSEC(20));
if (rc == 0) {
    struct state_msg *state = zbus_chan_msg(&state_chan);
    state->level = next_level;      /* 잠금 보유 중 직접 변경 */
    zbus_chan_finish(&state_chan); /* 반드시 짝지어 해제 */
    rc = zbus_chan_notify(&state_chan, K_MSEC(20));
    /* rc를 확인: 통지가 실패해도 앞선 직접 변경은 남을 수 있다 */
}

finish와 뒤이은 notify는 하나의 원자적 작업이 아니다. 두 호출 사이에 다른 게시자가 채널 값을 바꾸면 notify는 바뀐 현재 값을 알릴 수 있다. 자신이 수정한 값의 게시·통지를 한 잠금 구간으로 묶어야 하면 zbus_chan_pub()의 계약을 사용한다.

Listener callback은 게시자의 잠금 구간 안에서 실행되므로 같은 채널을 다시 claim하거나 read하는 대신 zbus_chan_const_msg()로 현재 메시지를 직접 본다. 반대로 비동기 subscriber는 통지 후 채널이 아직 잠겨 있을 수 있으므로 read의 timeout을 여유 있게 잡고 실패를 처리한다.

근거: read·notify·claim·finish 실제 잠금 경로, claim/finish/notify 공개 계약, listener 접근과 claim 예시, subscriber read timeout 경고.

5. 통지의 순서와 처리 완료의 순서를 섞지 않는다

3.7.0의 VDED는 채널 정의에 나열한 관찰자, ZBUS_CHAN_ADD_OBS로 붙인 정적 관찰자, 실행 중 추가한 관찰자의 순서로 통지한다. 첫 묶음은 정의 순서, 두 번째 묶음은 매크로의 sequence priority, 마지막 묶음은 추가 순서다. 비활성 관찰자나 가려진 observation은 건너뛴다. 이것은 VDED가 통지를 시도하는 순서다. 깨어난 비동기 스레드가 언제 처리까지 마칠지는 우선순위와 선점에 달려 있다.

통지 수신도 무조건 보장된다고 가정하지 않는다. Subscriber의 msgq가 가득 차면 통지 오류가 날 수 있고, message subscriber의 net_buf 확보도 실패할 수 있다. 후자는 설정에 따라 assert로 중단되거나 오류로 드러나므로 버퍼 풀 크기와 메모리 여유를 먼저 검증한다. Publish가 오류를 돌려주었다면 validator·잠금·관찰자 통지 중 어느 단계였는지 구분한다. CONFIG_ZBUS_MSG_SUBSCRIBER_NET_BUF_POOL_SIZE는 메시지 크기·생산 속도·소비 지연에 맞춰 정한다.

근거: 3.7.0의 세 통지 계층과 비활성 무시, 순서대로 통지하며 실패를 보존하는 구현, assert/mock 분기, 전달 한계와 풀 설정.

6. timeout은 채널 잠금뿐 아니라 게시 통지에도 걸린다

timeout은 validator나 listener callback의 실행을 강제로 중단하지 않는다. 따라서 호출 전체의 실행 시간 상한으로 읽으면 안 된다. 게시 중 계산한 남은 시간은 뒤이은 큐·버퍼 대기에 전달되며, callback 실행 비용은 별도로 제한해야 한다.

K_NO_WAIT는 “CPU 작업이 0”이라는 뜻이 아니다. ISR에서 publish하면 잠금을 기다리지는 않지만 VDED의 listener 호출과 메시지 복사·통지 시도는 여전히 ISR 문맥에서 실행된다. 긴 callback이나 큰 메시지 전달을 ISR 경로에 두지 않는다.

근거: ISR K_NO_WAIT 강제와 pub·read·claim 경로, 두 구독 대기의 ISR 금지, 게시자 문맥의 VDED, 공개 timeout·finish 계약.

7. 최신 상태, 모든 샘플, 즉시 반응 중 무엇이 필요한가

진단할 때는 publish 호출의 반환값만 남기지 말고 채널 이름, validator 결과, 잠금 대기, 관찰자별 통지 결과, subscriber 큐 깊이와 message subscriber 버퍼 풀 상태를 나란히 기록한다. 과거 샘플이 필요했는데 최신값만 보였다면 subscriber가 채널 참조를 받은 시점과 실제 read 시점을 먼저 비교한다.

근거: 3.7.0 사용 기준, subscriber의 과거값·풀 경계.

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

기준 문서는 Zephyr 3.7.0 zbus다. 구현은 같은 릴리스 commit의 zbus.c, 공개 타입과 API는 zbus.h에 고정했다. 위 각 절의 좁은 출처 링크는 실제 복사·잠금·통지 위치를 가리킨다.