단일 스레드가 할 수없는 여러 스레드는 무엇을 할 수 있습니까? [닫은]

스레드는 코드 실행 속도를 높일 수 있지만 실제로 필요합니까? 모든 코드 조각을 단일 스레드를 사용하여 수행 할 수 있습니까? 아니면 여러 스레드를 사용하여 수행 할 수있는 것이 있습니까?

우선, 스레드는 코드 실행 속도를 높일 수 없습니다. 컴퓨터가 더 빨리 실행되지는 않습니다. 그들이 할 수있는 일은 낭비되는 시간을 사용하여 컴퓨터의 효율성을 높이는 것입니다. 특정 유형의 처리에서이 최적화는 효율성을 높이고 실행 시간을 줄일 수 있습니다.

간단한 대답은 그렇습니다. 단일 스레드에서 실행할 코드를 작성할 수 있습니다. 증명 : 단일 프로세서 시스템은 명령을 선형으로 만 실행할 수 있습니다. 운영 체제 처리 인터럽트에 의해 여러 줄의 실행이 이루어지며 현재 스레드의 상태를 저장하고 다른 스레드를 시작합니다.

복잡한 대답은 더 복잡 ...입니다! 멀티 스레드 프로그램이 선형 프로그램보다 종종 더 효율적인 이유는 하드웨어 "문제"때문입니다. CPU는 메모리 및 하드 스토리지 IO보다 더 빠르게 계산을 실행할 수 있습니다. 예를 들어 "add"명령어는 "fetch"보다 훨씬 빠르게 실행됩니다. 캐시와 전용 프로그램 명령어 페칭 (여기서는 정확한 용어는 확실하지 않음)이 어느 정도까지는이 문제를 해결할 수 있지만 속도 문제는 남아 있습니다.

스레딩은 IO 명령어가 완료되는 동안 CPU 바운드 명령어에 CPU를 사용하여 이러한 불일치를 방지하는 방법입니다. 일반적인 스레드 실행 계획은 아마도 데이터 가져 오기, 데이터 처리, 데이터 쓰기입니다. 페치 및 쓰기는 3주기가 걸리고 처리는 설명을 위해 1주기가 걸린다고 가정하십시오. 컴퓨터가 읽거나 쓰는 동안 각각 2주기 동안 아무것도하지 않는 것을 알 수 있습니까? 분명히 게으르고 있으며 최적화 채찍을 깨야합니다!

이 낭비되는 시간을 사용하기 위해 스레딩을 사용하여 프로세스를 다시 작성할 수 있습니다.

1. # 1 가져 오기
2. 작동하지 않음
3. # 2 가져 오기
4. # 1 완료, 처리
5. 쓰기 # 1
6. # 1 가져 오기
7. # 2 완료, 처리
8. 쓰기 # 2
9. 가져 오기 # 2

등등. 분명히 이것은 다소 고안된 예이지만 IO를 기다리는 데 소비되는 시간을이 기술이 어떻게 활용할 수 있는지 알 수 있습니다.

위에 표시된 스레딩은 IO 바인딩 프로세스가 많은 경우에만 효율성을 높일 수 있습니다. 프로그램이 주로 일을 계산하는 경우 더 많은 작업을 수행 할 수있는 "홀"이 많지 않습니다. 또한 스레드 간을 전환 할 때 몇 가지 명령이 오버 헤드됩니다. 너무 많은 스레드를 실행하면 CPU가 대부분의 시간을 소비하고 실제로 문제를 해결하는 데 많은 시간을 소비하지 않습니다. 이것을 thrashing 이라고 합니다.

모든 것이 단일 코어 프로세서에는 적합하지만 대부분의 최신 프로세서에는 둘 이상의 코어가 있습니다. 스레드는 여전히 동일한 용도로 사용됩니다-CPU 사용을 최대화하지만 이번에는 두 개의 개별 명령을 동시에 실행할 수 있습니다. 이것은 컴퓨터가 컨텍스트 전환이 아니라 실제로 멀티 태스킹하기 때문에 사용 가능한 코어 수 만큼 실행 시간을 줄일 수 있습니다 .

여러 코어가있는 스레드는 두 코어간에 작업을 분할하는 방법을 제공합니다. 위의 내용은 여전히 ​​각 개별 코어에 적용됩니다. 하나의 코어에서 2 개의 스레드로 최대 효율을 실행하는 프로그램은 2 개의 코어에서 약 4 개의 스레드로 최대 효율로 실행될 가능성이 높습니다. (효율은 최소 NOP 명령 실행으로 측정됩니다.)

단일 코어가 아닌 여러 코어에서 스레드를 실행할 때 발생하는 문제는 일반적으로 하드웨어에 의해 처리됩니다. CPU는 읽기 / 쓰기 전에 적절한 메모리 위치를 잠그도록합니다. (메모리에 특수 플래그 비트를 사용한다는 것을 읽었지만 여러 가지 방법으로 달성 할 수 있습니다.) 고급 언어를 사용하는 프로그래머는 두 코어에서 더 이상 걱정할 필요가 없습니다. 하나와 관련이 있습니다.

TL; DR : 스레드는 작업을 분할하여 컴퓨터가 여러 작업을 비동기 적으로 처리 할 수 ​​있도록합니다. 따라서 프로세스가 리소스를 기다릴 때 잠금이 아니라 사용 가능한 모든 처리 시간을 활용하여 컴퓨터를 최대 효율로 실행할 수 있습니다.

단일 스레드가 할 수없는 여러 스레드는 무엇을 할 수 있습니까?

아무것도.

간단한 증거 스케치 :

• [교회 투어 추측] ⇒ 계산할 수있는 모든 것은 Universal Turing Machine으로 계산할 수 있습니다.
• 범용 튜링 머신은 단일 스레드입니다.
• Ergo, 계산 가능한 모든 것은 단일 스레드로 계산 될 수 있습니다.

그러나 거기에는 큰 가정이 숨겨져 있습니다. 즉 , 단일 스레드 내 에서 사용되는 언어 는 Turing-complete입니다.

더 흥미로운 질문은 " 튜링이 완료되지 않은 언어에 멀티 스레딩 만 추가 하면 튜링이 완료 될 수 있습니까?"입니다. 대답은 "예"입니다.

전체 기능 언어를 봅시다. [익숙하지 않은 사람들을 위해 : 함수형 프로그래밍은 함수를 사용한 프로그래밍과 마찬가지로, 전체 함수형 프로그래밍은 전체 함수를 사용한 프로그래밍입니다.]

전체 기능 언어 분명 튜링 완성되지 않은 : 당신이 TFPL에서 무한 루프를 쓸 수 없습니다 (사실, 그것은 거의의 정의 "전체"의)는,하지만 당신은 할 수 튜링 기계에, ERGO이 적어도 하나 개의 프로그램이 존재하는 TFPL은 TFPL로 작성할 수 없지만 UTM에서는 쓸 수 있으므로 TFPL은 UTM보다 계산 성능이 떨어집니다.

그러나 TFPL에 스레딩을 추가하자마자 무한 루프가 발생합니다. 새 스레드에서 루프의 각 반복을 수행하십시오. 모든 개별 스레드는 항상 결과를 반환하므로 결과는 Total이지만 모든 스레드는 다음 반복 을 실행 하는 새 스레드를 생성합니다 .

나는 생각 이 언어는 튜링 완성 될 것이라고.

최소한 원래의 질문에 대답합니다.

단일 스레드가 할 수없는 여러 스레드는 무엇을 할 수 있습니까?

경우 당신이 무한 루프를 할 수없는 언어를 가지고, 다음, 멀티 스레딩은 무한 루프를 수행 할 수 있습니다.

물론 스레드 생성은 부작용이므로 확장 언어가 더 이상 전체가 아니라 더 이상 기능적이라는 점에 유의하십시오.

이론적으로 멀티 스레드 프로그램이 수행하는 모든 작업은 단일 스레드 프로그램으로 수행 할 수 있습니다.

실제로 속도 차이가 너무 커서 작업에 단일 스레드 프로그램을 사용할 수있는 방법이 없습니다. 예를 들어 매일 밤 배치 데이터 처리 작업을 실행하고 단일 스레드에서 완료하는 데 24 시간 이상 걸리는 경우 멀티 스레드로 만드는 것 외에 다른 옵션이 없습니다. (실제로 임계 값은 훨씬 낮습니다. 종종 이러한 업데이트 작업은 사용자가 시스템을 다시 사용하기 전에 이른 아침까지 완료해야합니다. 또한 다른 작업은 해당 시스템에 따라 달라질 수 있으며 같은 밤에도 완료되어야합니다. 사용 가능한 런타임은 몇 시간 / 분으로 낮을 수 있습니다.)

여러 스레드에서 컴퓨팅 작업을 수행하는 것은 분산 처리의 한 형태입니다. 여러 스레드에 작업을 분배하고 있습니다. 분산 처리의 또 다른 예 (다중 스레드 대신 여러 컴퓨터 사용)는 SETI 화면 보호기입니다. 단일 프로세서에서 많은 측정 데이터를 처리하는 데 시간이 오래 걸리고 연구원들은 퇴직 전에 결과를 보는 것을 선호합니다. ;-) 슈퍼 컴퓨터를 오랫동안 빌릴 예산이 없기 때문에 수백만 대의 가정용 PC에 작업을 배포하여 저렴하게 만들 수 있습니다.

스레드는 순차적 계산에서 작은 단계 인 것처럼 보이지만 실제로는 큰 단계를 나타냅니다. 순차적 계산의 가장 중요하고 매력적인 속성 인 이해성, 예측 가능성 및 결정론을 버립니다. 계산 모델로서 쓰레드는 비결정론 적이며 프로그래머의 직무는 그 비결정론을 정리하는 것 중 하나가된다.

-스레드 문제 (www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf).

스레드를 사용하여 여러 코어에 작업을 분산시킬 수있는 성능 이점이 있지만 종종 많은 비용이 듭니다.

아직 언급되지 않은 스레드 사용의 단점 중 하나는 단일 스레드 프로세스 공간에서 얻을 수있는 자원 분할의 손실입니다. 예를 들어, segfault의 경우에 부딪쳤다 고 가정하십시오. 경우에 따라서는 장애가있는 자식을 죽이고 새 자식을 낳기 만하면 다중 프로세스 응용 프로그램에서이를 복구 할 수 있습니다. 이것은 Apache의 prefork 백엔드의 경우입니다. 하나의 httpd 인스턴스가 중단되면 더 나쁜 경우는 해당 프로세스에 대해 특정 HTTP 요청이 삭제 될 수 있지만 Apache는 새 자식을 생성하고 종종 재전송 및 서비스를 제공하는 경우 요청을 생성합니다. 결과적으로 아파치 전체가 아파치 스레드로 인해 중단되지 않습니다.

이 시나리오에서 고려해야 할 또 다른 사항은 메모리 누수입니다. 스레드 충돌을 정상적으로 처리 할 수있는 경우가 있습니다 (UNIX에서는 특정 신호에서 복구-segfault / fpviolation조차 가능합니다).이 경우에도 해당 스레드가 할당 한 모든 메모리가 누출되었을 수 있습니다 (멀록, 새 등). 따라서 프로세스가 계속 작동하는 동안 각 결함 / 복구마다 시간이 지남에 따라 점점 더 많은 메모리가 누출됩니다. 다시 말하지만, Apache의 메모리 풀 사용과 같이이를 최소화 할 수있는 방법이 있습니다. 그러나 이것은 여전히 ​​스레드가 사용 중일 수있는 타사 라이브러리에 의해 할당 된 메모리를 보호하지 않습니다.

그리고 일부 사람들이 지적했듯이 동기화 프리미티브를 이해하는 것이 실제로 제대로 달성하기가 가장 어려울 수 있습니다. 이 문제 자체는 모든 코드에 대한 일반적인 논리를 얻는 것만으로도 큰 골치 거리가 될 수 있습니다. 신비한 교착 상태는 가장 이상한 시간에 발생하기 쉽고 때로는 프로그램이 프로덕션 환경에서 실행될 때까지도 발생하지 않으므로 디버깅이 더 어려워집니다. 여기에 동기화 프리미티브가 플랫폼 (Windows 대 POSIX)에 따라 크게 다르고 디버깅이 더 어려울 수 있으며 경쟁 조건 (시동 / 초기화, 런타임 및 종료)의 가능성뿐만 아니라 쓰레드 프로그래밍은 초보자에게는 자비가 거의 없다. 전문가조차도 스레딩 자체에 대한 지식이 일반적으로 복잡성을 최소화하지 않기 때문에 여전히 자비가 거의 없습니다. 스레드 코드의 각 줄은 때때로 프로그램의 전체적인 복잡성을 기하 급수적으로 복잡하게 만들뿐만 아니라 숨겨진 교착 상태 또는 이상한 레이스 조건이 언제라도 나타날 가능성을 증가시킵니다. 이러한 것들을 제거하기 위해 테스트 케이스를 작성하는 것도 매우 어려울 수 있습니다.

이것이 Apache 및 PostgreSQL과 같은 일부 프로젝트가 대부분 프로세스 기반 인 이유입니다. PostgreSQL은 모든 백엔드 스레드를 별도의 프로세스로 실행합니다. 물론 이것은 여전히 ​​동기화 및 경쟁 조건의 문제를 완화 시키지는 않지만, 약간의 보호를 추가하고 어떤면에서는 사물을 단순화합니다.

단일 실행 스레드를 각각 실행하는 여러 프로세스가 단일 프로세스에서 실행되는 여러 스레드보다 훨씬 좋습니다. 그리고 AMQP (RabbitMQ, Qpid 등) 및 ZeroMQ와 같은 새로운 P2P 코드가 등장하면서 스레드를 다른 프로세스 공간과 머신 및 네트워크로 분할하는 것이 훨씬 쉬워졌습니다. 그러나 여전히 은총 알이 아닙니다. 여전히 다루기가 복잡합니다. 프로세스 공간에서 네트워크로 일부 변수를 이동하기 만하면됩니다.

결론은 스레드 도메인에 들어가는 결정이 가벼운 것이 아니라는 것입니다. 일단 그 영역으로 들어가면 거의 즉시 모든 것이 더욱 복잡해지고 완전히 새로운 유형의 문제가 삶에 들어갑니다. 재미 있고 시원 할 수 있지만 원자력과 비슷합니다. 일이 잘못되면 잘못되고 빠를 수 있습니다. 나는 몇 년 전에 비판 훈련에서 수업을 들었던 것을 기억하고 그들은 Los Alamos의 일부 과학자들의 사진을 WWII의 실험실에서 플루토늄과 함께 연주 한 것을 보여주었습니다. 많은 사람들이 노출 사건에 대해 거의 또는 전혀 예방 조치를 취하지 않았고 눈이 깜박 거릴 때 하나의 밝고 고통없는 플래시로 모든 것이 끝났습니다. 며칠 후에 그들은 죽었습니다. 리차드 페이 먼 (Richard Feynman)은 나중에 이것을 " 용의 꼬리를 간지럽 히는. "그것은 실을 가지고 노는 것이 (적어도 어쨌든) 어떤 것일 수 있습니다. 처음에는 오히려 무해한 것으로 보이며, 물린 시간에는 물건이 얼마나 빨리 신맛이 나는지 머리를 긁적입니다. 그러나 최소한 실은 이겼습니다. 널 죽이지 마

첫째, 단일 스레드 응용 프로그램은 멀티 코어 CPU 또는 하이퍼 스레딩을 사용하지 않습니다. 그러나 멀티 스레딩을 수행하는 단일 코어, 단일 스레드 CPU에서도 이점이 있습니다.

대안과 그것이 당신을 행복하게 만드는지 고려하십시오. 동시에 실행해야하는 여러 작업이 있다고 가정합니다. 예를 들어 두 개의 다른 시스템과 계속 통신해야합니다. 멀티 스레딩없이 어떻게합니까? 자신 만의 스케줄러를 작성하고 수행해야하는 다른 태스크를 호출하게 할 수 있습니다. 즉, 작업을 여러 부분으로 분할해야합니다. 부품이 너무 많은 시간을 소비하지 않도록해야하는 일부 실시간 구속 조건을 충족해야합니다. 그렇지 않으면 다른 작업에서 타이머가 만료됩니다. 이로 인해 작업을 나누기가 더 어려워집니다. 자신을 관리해야하는 작업이 많을수록 더 많은 분할 작업이 필요하며 스케줄러가 모든 제약 조건을 충족시키기가 더 복잡해집니다.

스레드가 여러 개인 경우 수명이 더 쉬워 질 수 있습니다. 선점 스케줄러는 언제든지 스레드를 중지하고 상태를 유지하며 다른 스레드를 다시 시작 (시작) 할 수 있습니다. 실이 회전하면 다시 시작됩니다. 장점 : 스케줄러 작성의 복잡성은 이미 완료되었으므로 작업을 분할 할 필요가 없습니다. 또한 스케줄러는 자신도 모르는 프로세스 / 스레드를 관리 할 수 ​​있습니다. 또한 스레드가 아무것도 할 필요가 없으면 (일부 이벤트를 기다리고 있음) CPU 사이클이 필요하지 않습니다. 다운 싱글 스레드 스케줄러를 작성할 때 달성하기 쉽지 않습니다. (자기 물건을 넣는 것은 그리 어렵지 않지만 어떻게 깨우나요?)

다중 스레드 개발의 단점은 동시성 문제, 잠금 전략 등에 대해 이해해야한다는 것입니다. 오류없는 멀티 스레드 코드를 개발하는 것은 매우 어려울 수 있습니다. 그리고 디버깅이 더 어려울 수 있습니다.

여러 스레드를 사용해야 만 달성 할 수있는 것이 있습니까?

예. 단일 스레드로 여러 CPU 또는 CPU 코어에서 코드를 실행할 수 없습니다.

여러 CPU / 코어가 없으면 스레드는 여전히 서버에서 클라이언트 처리와 같이 개념적으로 병렬로 실행되는 코드를 단순화 할 수 있지만 스레드없이 동일한 작업을 수행 할 수 있습니다.

스레드는 속도뿐만 아니라 동시성에 관한 것입니다.

@Peter가 제안한 배치 응용 프로그램이 아니라 WPF와 같은 GUI 툴킷이 하나의 스레드로 사용자 및 비즈니스 로직과 상호 작용하는 방법은 무엇입니까?

또한 웹 서버를 작성한다고 가정하십시오. 하나의 스레드로 동시에 두 명 이상의 사용자에게 서비스를 제공하는 방법은 무엇입니까 (다른 프로세스는 필요하지 않음)?

하나의 스레드만으로는 충분하지 않은 시나리오가 많이 있습니다. 그렇기 때문에 50 개 이상의 코어와 수백 개의 스레드가있는 Intel MIC 프로세서와 같은 최근의 발전이 이루어지고 있습니다.

예, 병렬 및 동시 프로그래밍이 어렵습니다. 그러나 필요합니다.

다중 스레딩을 사용하면 긴 처리 작업 동안 GUI 인터페이스가 계속 응답 할 수 있습니다. 멀티 스레딩이 없으면 긴 프로세스가 실행되는 동안 사용자는 잠긴 양식을보고있을 수 있습니다.

다중 스레드 코드는 단일 스레드가 할 수없는 방식으로 프로그램 논리를 교착 상태에 빠뜨리고 오래된 데이터에 액세스 할 수 있습니다.

스레드는 일반 프로그래머가 디버그하고 디버깅 할 것으로 예상되는 영역에서 모호한 버그를 취할 수 있습니다. 경고 프로그래머가 단지 적절한 순간.

다른 입력 (GUI 또는 기타 연결)에 응답해야하는 IO 차단을 처리하는 앱은 단일 스레드로 만들 수 없습니다

차단없이 읽을 수있는 양을 확인하기 위해 IO 라이브러리에 검사 방법을 추가하면 도움이 될 수 있지만 많은 라이브러리가 이것에 대해 완전히 보장하지는 않습니다.

좋은 답변이 많지만, 내가했던 것과 같은 문구는 확실하지 않습니다. 아마도 다른 방법으로 볼 수 있습니다.

스레드는 오브젝트 나 액터 또는 for 루프와 같은 프로그래밍 단순화 일뿐입니다 (예, if / goto로 구현할 수있는 루프로 구현하는 모든 것).

스레드가 없으면 단순히 상태 엔진을 구현합니다. 나는 이것을 여러 번해야했다. (내가 처음봤을 때, "상태"변수에 의해 제어되는 큰 스위치 문장을 만든 적이있다.) 상태 머신은 여전히 ​​일반적이지만 성 가실 수 있습니다. 나사산으로 보일러 플레이트의 거대한 덩어리가 사라집니다.

또한 언어가 런타임 실행을 다중 CPU 친화적 청크로 나누는 것이 더 쉬워졌습니다 (Actor도 믿습니다).

Java는 OS가 스레딩을 지원하지 않는 시스템에서 "그린"스레드를 제공합니다. 이 경우 그것들은 프로그래밍 추상화에 지나지 않는다는 것을 쉽게 알 수 있습니다.

OS는 각 스레드가 실행할 시간을 얻은 다음 선점되는 시간 분할 개념을 사용합니다. 이와 같은 접근 방식은 현재 스레딩을 대체 할 수 있지만 모든 응용 프로그램에서 고유 한 스케줄러를 작성하는 것은 과도합니다. 또한 I / O 장치 등을 사용해야합니다. 또한 하드웨어 측의 지원이 필요하므로 스케줄러를 실행하기 위해 인터럽트를 발생시킬 수 있습니다. 기본적으로 매번 새로운 OS를 작성하게됩니다.

일반적으로 스레드는 스레드가 I / O를 기다리거나 대기중인 경우 성능을 향상시킬 수 있습니다. 또한 긴 작업을 수행하는 동안 반응 형 인터페이스를 만들고 프로세스를 중지 할 수 있습니다. 또한 스레딩은 진정한 멀티 코어 CPU의 기능을 향상시킵니다.

첫째, 스레드는 동시에 둘 이상의 작업을 수행 할 수 있습니다 (코어가 둘 이상인 경우). 여러 프로세스에서이 작업을 수행 할 수도 있지만 일부 작업은 여러 프로세스에 잘 분산되지 않습니다.

또한 일부 작업에는 쉽게 피할 수없는 공간이 있습니다. 예를 들어, 디스크의 파일에서 데이터를 읽고 프로세스가 동시에 다른 작업을 수행하는 것은 어렵습니다. 작업이 디스크에서 많은 양의 데이터를 읽어야하는 경우 프로세스는 사용자가 무엇을 하든지 디스크를 기다리는 데 많은 시간을 소비합니다.

둘째, 스레드를 사용하면 성능에 중요하지 않은 대량의 코드를 최적화하지 않아도됩니다. 단일 스레드 만있는 경우 모든 코드 조각이 성능에 중요합니다. 그것이 막히면 당신은 가라 앉습니다. 그 과정에서 수행되는 작업은 앞으로 나아갈 수 없습니다. 스레드를 사용하면 블록은 해당 스레드에만 영향을 미치며 다른 스레드는 해당 프로세스에서 수행해야하는 작업을 수행 할 수 있습니다.

좋은 예는 자주 실행되지 않는 오류 처리 코드입니다. 작업에 매우 드물게 오류가 발생하고 해당 오류를 처리하는 코드가 메모리에 페이징되어야한다고 가정하십시오. 디스크가 사용 중이고 프로세스에 단일 스레드 만있는 경우 해당 오류를 처리하는 코드를 메모리에로드 할 수있을 때까지 앞으로 진행할 수 없습니다. 파열 반응이 발생할 수 있습니다.

또 다른 예는 데이터베이스 조회를 거의 수행하지 않아도되는 경우입니다. 데이터베이스가 응답하기를 기다리면 코드가 크게 지연됩니다. 그러나이 코드를 비 동기화하는 데 어려움을 겪고 싶지는 않습니다. 이러한 조회는 매우 드물기 때문입니다. 이 작업을 수행 할 수있는 스레드를 통해 두 가지 이점을 모두 누릴 수 있습니다. 이 작업을 수행하는 스레드는 성능을 중요하지 않게 만듭니다.