[트러블 슈팅] 항적 관리 간 삭제, 업데이트 충돌 문제 - Race Condition(경쟁 상태)

문제 발생

프로그램의 항적관리 기능 중 삭제 명령 시 기존 항적이 삭제되고 항적번호가 1 증가한 새로운 항적이 생성되어야하는데 간헐적으로 기존 항적이 삭제되지않고 남아있음.

 

원인 분석

1. 프로그램에서 항적이 전시되려면 타 체계에서 보낸 항적 정보가 담긴 메세지 구조체를 받아 우리 서버를 거쳐 Client로 보내는 방식

2. 메세지는 100ms 간격으로 들어오고 주기적으로 들어오는 메세지 정보를 받아 항적 정보(위치, 항적번호 등)를 업데이트하며 삭제가 아닌 메세지 정보가 끊기면 미상 항적으로 60초간 전시했다 삭제되는 방식

3. 타 체계에서 A라는 메세지를 보내다가 삭제 명령이 들어오면 B라는 메세지를 보내주는데 A가 출발한 상태에서 삭제메세지가 들어와 B라는 메세지를 보내주지만 이미 출발한 A라는 메세지는 그대로 Client까지 들어와 지도에 60초간 전시되며 삭제

 

Race Condition이란?

“둘 이상의 비동기 작업이 순서에 따라 서로 영향을 줄 수 있는 상황”에서,
“그 순서가 예측 불가능하거나 통제되지 않는 경우 발생하는 문제”

 

• 동시에 일어나는 처리 흐름이 있고, → map으로 항적을 관리하고 여기서 삭제 및 갱신 작업이 일어남(공유자원)
• 그 순서가 결과에 영향을 주며,  →  제대로 삭제가 이루어 진 후 업데이트 되어야 정상 작동함 
• 순서를 보장하지 못한다.  → 간헐적으로 순서가 충돌나면 위와 같은 문제가 발생

즉, 삭제명령과 업데이트 명령 두 개의 비동기 작업간 일어난 Race Condition - 순서 충돌 문제로 판단하였음.

 

해결 방법

1. Race Condition을 해결하는 방법 중에 뮤텍스를 이용한 방법이 있다길래 항적을 관리하는 Map을 뮤텍스로 묶어 제어 - 실패

  → 뮤텍스는 하나의 공유자원에 동시에 접근하지 못하게 하는 기능으로 동시충돌제어에는 해결방법이 될 수 있으나, 우선 순위를 보장해주지는 못함.

2. 우리측 서버에서 2차 검증 로직으로 DeleteList를 만들어 관리

  가.  삭제 명령 시 Delete List에 해당 항적 번호를 등록

  나.  갱신 명령 시 Delete List에 해당 항적 번호가 있는 지 조회 후 남아있다면 추가 삭제

  다. 일정 시간 이후 Delete List에서 해당 항적 번호 삭제(300ms)

  ※ 나. 추가삭제 구간에서 업데이트 뮤텍스로 잠긴 상태에서 삭제명령으로 다시 잠금 시도 해 데드락 발생

       → 업데이트 구간 삭제 시 뮤텍스 없는 삭제 명령 함수를 만들어 해결