인텔 TBB 네트워크 연결 서비스 - 좋은 모델입니까?

Question

12 개의 클라이언트 (N = 10-100)를 제공하는 네트워킹 제품의 백엔드를 개발 중입니다. 각각의 연결은 2 회의 주기적 작업, 즉 하트 비트와 SSH를 통한 텔레 메 트리 다운로드를 필요로하며, 각각은 H Hz입니다. 프론트 엔드에서 나오는 다른 종류의 이벤트도 있습니다. 모든 작업의 ​​성격 상, OS가 응답을 기다리는 동안 다른 클라이언트를 제공하기 위해 자주 스레드간에 전환 할 수 있도록 각 연결의 소켓에서 select 호출을 기다리는 견고한 부분이 있습니다.

초기 구현에서는 하트 비트, 원격 측정, 추가) 당 3 개의 스레드를 생성하고 각각 단일 조건 변수를 기다리고 있습니다.이 변수는 작업 큐에서 수행 할 작업이있을 때마다 겹쳐서 표시됩니다. 작업 대기열은 타이머와 프론트 엔드의 명령을 사용하여 위에서 언급 한주기적인 이벤트로 채워집니다.

여기에 몇 가지 질문이 있습니다.

1. 작업자 스레드 풀 접근 방식을 Intel TBB 작업으로 전환하는 것이 좋습니까? 그렇다면 어떤 스레드 값을 tbb::task_scheduler_init으로 초기화해야합니까? 300 개 스레드 signal ED 초당 N * H * 3 번이고 조건 변수에 대기와 현재의 접근법에서

2. , (특히 signal 호출 측) 확장 성을위한 병목 현상이 예상된다. 작업 당 한 명의 작업자 만 깨우는 더 좋은 방법이 있습니까?

3. TBB에서 워킹 스레드 깨우기는 어떻게 이루어 집니까?

의견을 보내 주셔서 감사합니다.

Answer 1

TBB로 전환하면 좋은 접근 방법이 될지 말하기가 어렵습니다. 성능 요구 사항은 무엇이며 현재 구현의 성능 수치는 무엇입니까? 현재의 솔루션이 충분하다면 전환 할 가치가없는 것보다

더 나은 성능을 제공하는 두 가지 (현재 impl 대 TBB)를 비교하려면 각 구현에 대해 "추적자 글 머리표"(The Pragmatic Programmer)를 수행하고 결과를 비교할 수 있습니다. 간단히 말하자면, 각각의 프로토 타입을 줄이고 결과를 비교하십시오.

this answer에서 언급했듯이 변경하려는 내용이 개선 될 것이라는 구체적인 증거없이 성능 향상을 시도하는 것은 일반적으로 바람직하지 않습니다.

이 외에도 스레드 수를 CPU 코어 수 (코어 당 1 또는 1.5 스레드)의 함수로 사용하는 스레드 풀을 만드는 것이 좋습니다. 스레드는 공통 작업 큐. 하트 비트, 텔레 메 트리, 엑스트라 등 세 가지 유형의 작업이 있습니다. 이렇게하면 많은 수의 스레드를 사용할 때 컨텍스트 전환으로 인한 부정적인 영향을 줄일 수 있습니다.