RTOS 기반 설계에서 리소스 공유

이 글은 RTOS 전문가 Jean J. Labrosse가 작성했습니다.

 

RTOS는 각 태스크가 CPU를 자체적으로 가지고 있다고 생각하게 하지만 태스크는 작업을 수행하기 위해 종종 변수, 테이블, 데이터 구조 및 I/O 장치와 같은 리소스를 공유해야 합니다. 선점 가능성 때문에 태스크는 공유 리소스에 대한 배타적 액세스 권한을 확보해야 합니다.

일반적으로 RTOS는 인터럽트 활성화/비활성화, 스케줄러에 의한 태스크 전환하 방지(스케줄러 잠금/잠금 해제), 세마포어 및 상호 배제 세마포어와 같이 상호 배제를 보장하기 위한 많은 서비스를 제공합니다. 실제 사용되는 메커니즘은 상황에 따라 다릅니다.

응용 프로그램이 수개의 CPU 클럭 사이클 내에서 간단한 변수에 액세스할 수 있으면 인터럽트를 비활성화하고

변수에 액세스한 다음 인터럽트를 다시 활성화하는 것이 가장 좋습니다.

리소스에 액세스하는 데 수천 개의 CPU 사이클이 필요한 경우에는, 1960년대 초반 Edsger Dijkstra가 정의한 바와 같이 (일반) 세마포어를 사용할 때 발생할 수 있는 문제인 끝없는 우선 순위 반전을 피할 수 있는 상호 배제 세마포어(일명 뮤텍스)를 사용하는 것이 가장 좋습니다. 

아래의 코드 스니핏에 대한 그림은 뮤텍스 메커니즘 사용법을 보여줍니다.

주의할 점은 뮤텍스를 사용하려면 먼저 뮤텍스를 생성(즉, 초기화)해야 한다는 것입니다. 모든 RTOS에는 이를 위한 메커니즘이 있으므로 사용 중이거나 사용할 계획인 RTOS의 문서를 참조하십시오.

한 태스크가 다른 태스크가 소유한 리소스에 액세스 할 때 교착 상태가 발생합니다. 모든 태스크가 필요한 모든 리소스에 동일한 순서로 액세스하고 역순으로 해제하는 데 동의하면 교착 상태를 피할 수 있습니다.  

아래 표시된 코드 스니핏은 여러 리소스에 올바르게 액세스합니다. 두 뮤텍스가 모두 있으면 기술적으로 리소스 A 또는 B에 어떠한 순서로든 액세스할 수 있습니다.

또한 타임아웃 메커니즘을 제공하는 RTOS는 교착 상태를 피할 수 있습니다. 특히 타임아웃은 태스크가 리소스가 해제될 때까지 한없이 기다리는 것을 방지합니다.

그러나 타임아웃으로 인해 'Get()'에서 반환하는 것은 태스크가 리소스에 액세스할 수 없다는 것을 의미하므로 코드가 그에 따라 상황을 처리해야 합니다. 즉, 리소스에 대한 독점적인 액세스 권한이 없기 때문에 해당 리소스에 액세스하면 안됩니다!

리소스 경합은 서버 태스크를 만들어 피할 수 있습니다. 서버 태스크는 항상 리소스를 소유하고 클라이언트 태스크는 서버에 서비스를 요청합니다.

아래의 예와 같이 태스크(서버)은 현재 시간(일, 월, 연도, 요일 등)을 추적하는 역할을 합니다. 클라이언트는 서버 태스크 개발자가 제공한 API를 통해 서버에 다음을 요청할 수 있습니다.

• 현재 날짜/시간을 ASCII 문자열로 반환 (Clk_GetDateTimeASCII())
• 시간 변경 (Clk_SetTime())
• 날짜 변경 (Clk_SetDate())
• 기타

API는 단지 요청을 대기열에 넣고 서버가 요청을 순서대로 처리합니다. 이 예에서는 시계 태스크가 항상 시계 변수에 독점적으로 액세스할 수 있으므로 다른 태스크나 ISR과 이를 공유할 필요가 없습니다.

이 체계를 통해 리소스 공유와 관련된 많은 문제를 피할 수 있습니다.

 

더 자세히 알고 싶습니까?

주문형 웨비나(RTOS를 통한 임베디드 응용 프로그램 멀티태스킹의 이점) 및 (RTOS 기반 응용 프로그램의 더 나은 디버깅을 위한 팁과 힌트)를 확인하십시오.