처음에

여기에서는 INtime/iRFW 어플리케이션의 개발에 대해 빠지기 십상인 좋지 않는 처리의 실장과 그 이유에 대해 해설하고 있습니다. 어플리케이션 개발의 힌트로 사용해 주세요.

 

1. 폴링에 의한 Busy 루프

 void AnalogInputThread( void )
 {
     SetRtThreadPriority( NULL_RTHANDLE ,140 );
 
     while( 1 ) {
     
         // AD변환 개시 지령
         SamplingStart( CH1 );
 
         // AD변환의 완료 대기(Busy 루프)
         while( (inbyte( ADC_STATUS_REG ) & MASK) == SAMPLING_BUSY ) {
             dwWaitCount++;
         }
 
         // AD변환 데이터를 취득
         SamplingDataGet( CH1 );
     }
 }

아이들타임을 가지지 않는 스레드의 존재는, 리얼 타임 처리계에 있어서의 처리 우선도의 개념을 별로 이해되어 있지 않은 프로그래머가 빠지기 쉬운 잘못입니다.

이 예에서는 AD변환 완료를 기다리기 위해서, 플래그의 변화를 폴링 처리로 확인하고 있습니다만, 이 루프 구간은 아이들타임을 전혀 가지지 않는 구조 때문에, 영속적으로 CPU를 계속 사용하는 처리가 되고 있습니다.  그 결과, 이 스레드보다 우선도의 높은 스레드는 이 스레드를 일시적으로 멈추어 처리 가능하지만, 한 편으로 이 스레드보다 우선도의 낮은 스레드에는 실행의 찬스가 방문하지 않는 것을 이해할 필요가 있습니다.

특히 Windows를 최저 우선도의 게스트스레드로서 맞아들이고 있는 INtime 아키텍쳐에서는, Windows의 실행 찬스가 없어져, 외관상 Windows가 무겁게 느낀다,  혹은 다운 당한 것처럼 보이는 것이 특징으로 INtime의 이점을 살리는 것을 전혀 할 수 없게 됩니다.

INtime에 한정하지 않고 리얼 타임 처리계에서는, 장시간에 이르는 폴링 처리를 실시하는 경우 일정시간 간격마다 폴링 하는 것이 저우선도 처리의 동작을 보증하는데 있어서 필요하게 됩니다. 이 때문에 폴링 처리에는 많이 RtSleep(10)나 knRtSleep(1) 등에 의하는 휴식의 시간을 설치할 의무가 있습니다. 무엇보다, 쓸데 없게 CPU 파워를 낭비해 버리는 폴링 처리는 리얼 타임 처리계에서는 적절한 것이라고는 부르지 못하고, 본래 이러한 처리는 인터럽트 처리 방식으로서 개발되어야 합니다.

 

2. 고빈도인 표시 요구

 void WorkMoveThread( void )
 {
     while( 1 ) {
 
         WaitForRtSemaphore( hTrigger ,1 ,WAIT_FOREVER );   // 방아쇠 대기
        
         dwWorkMove = 0;
         while( dwWorkMove++ < numpos ) {
             outhword( X1REG  ,xpos[dwWorkMove] );
             outhword( Y1REG  ,ypos[dwWorkMove] );
             outhword( DATREG ,0xfffe );
             outhword( CMDREG ,0x0001 );
 
             RtSleep( 10 );
 
             printf( "WorkMove (%u) \n" ,dwWorkMove );         // 디버그 표시
         } 
     }
 }

INtime에서는 콘솔 입출력과 파일 입출력의 요구는, Windows에 인도해져 처리됩니다. 즉 Windows와의 거래를 수반하기 때문에 이러한 입출력 처리를 콜 하는 스레드는 Windows의 부하에 좌우되어 리얼타임성을 해치는 것에 주의합니다.

Windows에 충분한 실행 시간을 주지 않는 채 반복해지는 리얼 타임 처리측에서의 고빈도 입출력 요구는, Windows측에게의 부담을 누적적으로 증대시켜, 결과적으로 입출력 요구에 대한 처리가 늦은 상황에 빠지는 악순환이 됩니다.

콘솔/파일 입출력 처리가 기기의 제어 주기를 어지럽히는 것이 없게 하려면 , 제어 스레드와 표시 스레드를 분할하는 수법을 취할 수 있습니다.

 

3. 오브젝트 생성 삭제의 반복

 void WorkerThread( void )
 {
    Todo( );
    DeleteRtThread( NULL_RTHANDLE );  // 자스레드의 삭제
 }
 
 void ManagerThread( void )
 {
    while( 1 )
    {
        WaitForRtSemaphore( hEvent ,1 ,WAIT_FOREVER );
 
        // 작업 스레드의 생성
        CreateRtThread( 180 ,WorkerThread ,4096 ,0 );
    }
 }

24시간 가동을 전제로 하는 제어 시스템에 대해서는, 스레드, 메모리등의 오브젝트를 생성·삭제 반복하지 않는 구조가 이상입니다.1개는 생성/삭제 처리가 쓸데 없는 오버헤드가 되는 것이 이유입니다. 2개째에 메모리 부족등 하등의 이유로부터, 어느A 오브젝트의 생성은 실패할 가능성이 있을 수 있는 것입니다.

어플리케이션 프로세스는 기동시에 있고, 실행에 필요한 오브젝트를 모두 생성해 두고, 이후 그것을 삭제하는 일 없이 사용해 돌리는 처리 구조에 배려하면, 틀림없이 실행중의 생성 실패에 의한 시스템 다운은 막을 수 있습니다.

 

4. 과도한 스레드 분할

 void Stage1Thread( void )
 {
    while( 1 )
    {
        RtSleep( 1000 );
     
        ReleaseRtSemaphore( hStart2 ,1 );                // Stage2Thread의 개시
        todo1( );
        WaitForRtSemaphore( hEnd2 ,1 ,WAIT_FOREVER );    // Stage2Thread의 종료 대기
    }
 }
 
 void Stage2Thread( void )
 {
    while( 1 )
    {
        WaitForRtSemaphore( hStart2 ,1 ,WAIT_FOREVER );  // 기동 대기
 
        ReleaseRtSemaphore( hStart3 ,1 );                // Stage3Thread의 개시
        todo2( );
        WaitForRtSemaphore( hEnd3 ,1 ,WAIT_FOREVER );    // Stage3Thread의 종료 대기
 
        todo3( );
        ReleaseRtSemaphore( hEnd2 ,1 );                  // 완료를 통지
    }
 }
 
 void Stage3Thread( void )
 {
    while( 1 )
    {
        WaitForRtSemaphore( hStart3 ,1 ,WAIT_FOREVER );  // 기동 대기
        todo4( );
        ReleaseRtSemaphore( hEnd3 ,1 );                  // 완료를 통지
    }
 }

기능 단위에 스레드를 나누는 것은 유효한 공법입니다만, 너무 나누면 오히려 가시성이나 점검 성을 해치고, 스레드의 변환에 필요로 하는 OS오버헤드나 자원 소비가 쓸데 없게 증대합니다. 예를 들어 스레드간의 동기 구조를 가지는 케이스에서는, 함수 나누기로 끝마치는 것이 오히려 유효한 경우가 있습니다.