RTOS에서 대기열 교체

태스크 간 통신 또는 RTOS의 두 태스크간에 데이터를 공유하기 위해 큐를 사용합니다. 그러나 큐의 문제점은 느리다는 것입니다. 버퍼에서 데이터를 복사 한 다음 Mutex 처리 및 데이터 전송으로 복사합니다. 대용량 데이터를 전송해야한다면 짜증이납니다. 또 다른 문제는 여러 작업에서 동일한 대기열에 액세스하는 경우입니다. 그런 다음 그림은 다음과 같습니다 .- 먼저 대기열에 액세스하기 위해 대기 한 다음 대기열 내부 뮤텍스 처리 및 데이터 전송.

이것은 시스템의 오버 헤드를 증가시킵니다. 대기열을 효율적으로 대체 할 수있는 것은 무엇입니까 ?

(이 질문은 우리가 사용하는 RTOS와 무관합니다. 대부분의 RTOS는 이러한 방식으로 대기열을 처리합니다)

대기열은 작업 간 통신을위한 스레드 안전 트랜잭션 모델이므로 이러한 방식으로 작동합니다. 덜 엄격한 체계에서 데이터 손상 및 / 또는 소유권 문제가 발생할 위험이 있습니다.

데이터를 메모리의 버퍼에 복사 한 다음 큐 요소와 함께 포인터를 전달하거나 큐 요소 자체의 모든 데이터를 전달하려고합니까? 포인터를 전달하지 않으면 대기열 요소를 통해 한 번에 1 바이트를 전달하는 대신 성능이 향상됩니다.

쉬운 방법 중 하나는 큐에있는 데이터에 포인터를 놓고 포인터를 사용하여 데이터를 소비하는 것입니다.

다음과 같은 사항을 확인해야하므로 성능을 위해 안전을 거래해야합니다.

1. 소비자가 데이터를 소비 할 때까지 버퍼는 계속 유효합니다.
2. 누군가 버퍼 할당을 해제

동적으로 할당 된 메모리를 사용하지 않는 경우 할당을 해제 할 필요는 없지만 데이터를 사용하기 전에 메모리 영역을 다시 사용하지 않아야합니다.

단일 생산자 / 단일 소비자 사례에 대해 잠금없는 대기 행렬을 구현할 수 있으며, 종종 다중 생산자 또는 다중 소비자 대기 행렬 수를 최소화하도록 소프트웨어를 설계 할 수 있습니다.

잠금이없는 큐는 다음과 같이 구성 될 수 있습니다. 통신 할 요소의 배열과 두 개의 정수를 할당하여 헤드와 테일이라고합니다. Head는 배열에 대한 인덱스이며 다음 항목이 추가됩니다. Tail은 배열에 대한 색인이며 다음 항목을 제거 할 수 있습니다. 생산자 작업은 H 및 T를 읽고 항목을 추가 할 여지가 있는지 확인합니다. 소비자 작업은 H와 T를 읽고 사용 가능한 데이터가 있는지 확인하고 인덱스 T에서 데이터를 읽은 다음 T를 업데이트합니다. 기본적으로 두 작업에서 액세스하는 링 버퍼입니다. 작업 순서 (삽입, 업데이트 H, 제거, 업데이트 T)는 데이터 손상이 발생하지 않도록합니다.

여러 생산자 및 단일 소비자 또는 단일 생산자 및 여러 소비자가있는 상황이있는 경우에는 사실상 리소스 제한이 있으며 성능 제한 기가 잠금 메커니즘이있는 OS 오버 헤드보다 유일한 생산자 / 소비자입니다.

그러나 생산자와 소비자가 여러 명이라면 디자인 공간에서 시간을 투자하여보다 체계적인 의사 소통 메커니즘을 얻을 수 없는지 확인할 가치가 있습니다. 이와 같은 경우 단일 큐를 통해 모든 것을 직렬화하면 큐의 효율성이 성능의 중심 결정 요인이됩니다.

큐 자체에로드 스토어 독점, 비교 교환 또는 유사한 기본 요소와 작업하기에 충분히 작은 항목이 큐에 있으면 잠금없는 다중 생산자 단일 소비자 큐에서 효율적인 조작을 얻을 수 있습니다. 빈 대기열 슬롯에 예약 된 값 또는 예약 된 값. 대기열에 쓸 때 기록기는 비교 교환을 수행하여 데이터를 다음 빈 슬롯에 저장하려고 시도합니다. 실패하면 기록기는 다음 슬롯을 시도합니다. 대기열이 다음 빈 슬롯에 대한 포인터를 유지하지만 포인터 값은 "권고"입니다. 시스템이로드 스토어 독점이 아닌 비교 교환을 사용하는 경우, 다른 '빈 슬롯'값의 '패밀리'가 필요할 수 있습니다. 그렇지 않으면, 작성기가 빈 큐 슬롯을 찾아서 쓰기를 시도하면, 다른 작가는 슬롯을 쓰고 독자는 그것을 읽습니다. 첫 번째 작가는 자신도 모르는 곳에 자신의 데이터를 넣을 수 있습니다. 상점 독점은 데이터가 이전 값으로 다시 쓰여지더라도 기록되었음을 감지하므로로드 저장소 독점을 사용하는 시스템에서는이 문제점이 발생하지 않습니다.

대기열 위에 쓰면보다 효율적으로 대기열에 액세스 할 수 있습니다. 일반적으로 대부분의 RTOS는 뮤텍스를 획득 할 필요가없는 대기열 앞에 추가 할 수 있도록 지원합니다. 그러나 데이터를 더 빠르게 실행하려는 경우 가능한 한 대기열 앞에 추가를 사용하십시오. 일반적으로 대기열 구조에는 최대 크기 제한이 있으므로 모든 데이터를 대기열에 넣지 않을 수 있으므로 포인터를 전달하는 것이 항상 쉽습니다.

건배!!

큐는 본질적으로 느리지 않습니다. 그것들 의 구현 이 될 수 있습니다.

맹목적으로 데이터를 복사하고 동기 대기열을 사용하는 경우 성능이 저하됩니다.

다른 포스터에서 알 수 있듯이 잠금이없는 대안이 있습니다. 단일 생산자 / 단일 소비자 사례는 간단합니다. 여러 생산자 및 소비자의 경우 Michael과 Scott 의 잠금없는 큐 알고리즘 (이름은 성)이 표준이며 Java의 ConcurrentLinkedQueue 의 기본으로 사용됩니다 .

경우에 따라 대기열의 필요성을 최적화 할 수는 있지만 일반적으로 작업을 분리하여 시스템에 큰 단순화 이점을 제공하는 동시성 보장을 제공합니다.