19.4.2. 업데이트 확인(Update Check) 기반의 폴링 메커니즘

19.4.2. 업데이트 확인(Update Check) 기반의 폴링 메커니즘

직전 19.4.1 단원에서 지긋지긋하게 파헤쳐 본 무지성 단순 읽기(Simple Read) 방식과 1차원적인 타임스탬프(timestamp) 델타(Delta) 비교 방식은 기능적으로 확실히 동작하긴 하지만, 픽스호크 펌웨어 코어 설계의 미학적, 하드웨어적 관점에서 볼 때 대단히 비효율적이고 무식한(Brute-force) 쓰레기 하급 아키텍처이다.

냉정하게 시스템의 낭비를 역산해 보자. 매 루프 사이클 주기마다 코더는 orb_copy()라는 매우 무거운 시스템 콜(System Call)로 커널의 링 버퍼를 강제로 열어젖혀 메모리 바이트 덩어리를 통째로(예: 32바이트 구조체 전체) 내 로컬 스레드 스택 공간에 억지로 강제 복사(memcpy)해 온다.
그런 다음 스레드가 그 복사된 박스의 뚜껑을 열어서 “어라? 8바이트 타임스탬프 숫자가 아까 저번 루프에서 봤던 거랑 똑같네? 썩은 쓰레기 값이었군, 헛수고했네. 통째로 폐기하자!“를 1초에 100번씩 반복하는 행위. 이것은 마치 빈 물리적 우체통을 하루 100번씩 열어 편지가 있는지 확인하고 없으면 뚜껑을 닫고 되돌아가는, 그야말로 지독하고 처참한 I/O(Input/Output) 대역폭 병목 및 CPU 캐시 전력 낭비의 극치이다.

1. 우아하고 가벼운 VFS 메모리 변동 알림: Update Check 아키텍처

이러한 무의미한 중복 메모리 복제(memcpy) 오버헤드를 0%로 완전히 박살 내기 위해, PX4 시스템 미들웨어는 구독자 모듈을 위해 한 단계 더 진보된 ‘업데이트 확인(Update Check)’ C 매크로 메커니즘을 코어 단에서 제공한다.
이 방식의 설계 코어 물리적 아이디어는, 데이터를 무식하게 힙/스택으로 먼저 뜯어와서 까보는 것이 절대로 아니다. VFS 미들웨어 커널을 향해 **“혹시 내가 아까 저번 사이클에 파이프를 열어 읽어간 이후로, 저 버퍼 꼬리단에 새로운 데이터 갱신(Update) 플래그가 한 번이라도 나부꼈는가?”**라고 아주 가벼운 상태 플래그(Flag) 확인만 선제타격으로 물어보는 것이다.

이 영리한 방식은 프로세스 코드 내에서 다음과 같은 흐름 제어 플로우 아키텍처로 전개된다.

  1. 가벼운 링 버퍼 껍데기 노크 (orb_check): 주기적으로 도는 while 루프 최상단에서 가장 먼저, 아주 가벼운 불리언(Boolean) 반환 형태의 orb_check() 함수를 단발로 호출하여, 나에게 할당된 FD(File Descriptor) 파이프망에 새 데이터가 생성되었는지 VFS 레지스터 껍데기만 톡 노크해 본다.
  2. 강력한 스킵(Skip) 모드 분기: 만약 커널이 “업데이트 없음(False)“을 반환한다면, 무거운 orb_copy() 메모리 복사를 헛수고로 부를 이유가 1%도 없으므로 즉각 이번 루프 자체를 스킵(continue)하고 바로 하단 슬립(Sleep) 수면에 들어간다.
  3. 확정된 순수 데이터의 수확 타격: 커널이 업데이트를 확정(True)했을 때만 비로소 강력한 orb_copy()를 때려 100% 생존이 보장된 새로운 데이터만을 보람차게 메모리에 복제 탈취해 온다.

orb_check 아키텍처를 while 루프단에 새로 도입하는 바로 그 순간, 당신의 스레드 데몬은 의미 없는 C++ 메모리 강제 딥 카피(memcpy) 오버헤드와 L1 캐시 미스(Cache Miss) 파괴를 극단적으로 방어하면서, 오직 링 버퍼 데이터가 새롭게 유효할 때만 정밀하게 연산력을 소비하는 한층 성숙하고 영리한 코어 에이전트로 펌웨어 상에서 거듭나게 된다.