최근 리눅스에서 프로세스를 처리하는 데 매우 효율적이며 스레드와 관련된 많은 문제 (예 : 잠금)가 있기 때문에 Linux에서는 스레드 대신 프로세스를 사용하는 것이 거의 항상 좋다고 말하는 사람들이 있습니다. 그러나 스레드가 일부 상황에서 상당히 큰 성능 향상을 가져올 수있는 것처럼 보이기 때문에 의심됩니다.

그래서 내 질문은 스레드와 프로세스가 모두 잘 처리 할 수있는 상황에 처했을 때 프로세스 또는 스레드를 사용해야합니까? 예를 들어, 웹 서버를 작성하는 경우 프로세스 또는 스레드 (또는 조합)를 사용해야합니까?

리눅스는 1-1 스레딩 모델을 사용하는데, 커널과 프로세스와 스레드를 구분하지 않고 모든 것이 실행 가능한 작업입니다. *

리눅스에서 시스템 호출은 clone그중 공유의 구성 수준으로, 작업을 복제합니다 :

• CLONE_FILES: 사본을 작성하는 대신 동일한 파일 디스크립터 테이블을 공유하십시오.
• CLONE_PARENT: 새 작업과 이전 작업간에 부모-자식 관계를 설정하지 마십시오 (그렇지 않으면 childs getppid()= parent 's getpid())
• CLONE_VM: COW 사본 을 작성하는 대신 동일한 메모리 공간을 공유하십시오.

fork()호출 clone(이상 공유 )및 pthread_create()통화 clone(대부분의 공유 ). **

forking pthread_create은 테이블을 복사하고 메모리에 대한 COW 매핑을 생성하기 때문에 ing 보다 약간 더 많은 비용이 들지만 Linux 커널 개발자는 이러한 비용을 최소화하려고 노력했습니다.

동일한 메모리 공간과 다양한 테이블을 공유하는 작업 사이의 전환은 데이터가 이미 캐시에로드되어 있기 때문에 공유하지 않는 것보다 약간 저렴합니다. 그러나 아무 것도 공유하지 않아도 작업을 전환하는 것은 여전히 ​​매우 빠릅니다. 이것은 Linux 커널 개발자가 확인하려고 노력하는 것입니다.

실제로 다중 프로세서 시스템을 사용하는 경우 공유 하지 않는 것이 실제로 성능에 도움이 될 수 있습니다. 각 작업이 다른 프로세서에서 실행중인 경우 공유 메모리를 동기화하는 데 많은 비용이 듭니다.

* 단순화. CLONE_THREAD신호 전달이 공유되도록합니다 ( CLONE_SIGHAND필수, 신호 핸들러 테이블을 공유 함).

** 간체. 이 모두 존재 SYS_fork하고 SYS_clone콜을하지만, 커널의를 sys_fork과 sys_clone같은 주위 모두 매우 얇은 래퍼 do_fork자체가 주위에 얇은 래퍼입니다 기능 copy_process. 예, 용어 process, thread그리고 task리눅스 커널에 오히려 의미로 사용됩니다 ...

Linux (실제로 Unix)는 세 번째 옵션을 제공합니다.

옵션 1-프로세스

응용 프로그램의 일부 (또는 모든 부분)를 처리하는 독립 실행 형 실행 파일을 만들고 각 프로세스마다 별도로 호출합니다. 예를 들어, 프로그램은 자체 복사본을 실행하여 작업을 위임합니다.

옵션 2-스레드

단일 스레드로 시작하는 독립형 실행 파일을 작성하고 일부 태스크를 수행하기 위해 추가 스레드를 작성하십시오.

옵션 3-포크

Linux / Unix에서만 사용할 수 있으며 약간 다릅니다. 분기 프로세스는 실제로 자체 주소 공간이있는 자체 프로세스입니다. 자식이 부모 또는 형제 주소 공간 (스레드와 달리)에 영향을주기 위해 (일반적으로) 수행 할 수있는 작업이 없으므로 견고성이 추가됩니다.

그러나 메모리 페이지는 복사되지 않고 기록 중 복사되므로 일반적으로 생각보다 적은 메모리가 사용됩니다.

다음 두 단계로 구성된 웹 서버 프로그램을 고려하십시오.

1. 구성 및 런타임 데이터 읽기
2. 페이지 요청 제공

스레드를 사용한 경우 1 단계는 한 번 수행되고 2 단계는 여러 스레드에서 수행됩니다. "전통적인"프로세스를 사용한 경우 각 프로세스에 대해 1 단계와 2 단계를 반복해야하며 구성 및 런타임 데이터를 저장하기위한 메모리가 복제됩니다. fork ()를 사용한 경우 1 단계를 한 번 수행 한 다음 fork ()를 수행하여 런타임 데이터와 구성을 메모리에 그대로두고 그대로 그대로 복사 할 수 있습니다.

따라서 실제로 세 가지 선택이 있습니다.

그것은 많은 요인에 달려 있습니다. 프로세스는 스레드보다 무겁고 시작 및 종료 비용이 높습니다. 프로세스 간 통신 (IPC)도 스레드 간 통신보다 어렵고 느립니다.

반대로 각 프로세스는 자체 가상 주소 공간에서 실행되므로 프로세스는 스레드보다 안전하고 안전합니다. 하나의 프로세스가 충돌하거나 버퍼 오버런이 발생하면 다른 프로세스에는 전혀 영향을 미치지 않지만 스레드가 충돌하면 프로세스의 다른 스레드가 모두 중단되고 스레드에 버퍼 오버런이 있으면 스레드가 열립니다. 모든 스레드의 보안 구멍.

따라서 통신 모듈을 거의 사용하지 않고 응용 프로그램 모듈을 대부분 독립적으로 실행할 수있는 경우 시작 및 종료 비용을 감당할 수있는 경우 프로세스를 사용해야합니다. IPC의 성능 저하는 최소화되며 버그 및 보안 허점에 대해 약간 더 안전합니다. 모든 약간의 성능이 필요한 경우 복잡한 데이터 구조와 같은 많은 공유 데이터를 얻거나 가질 수 있다면 스레드와 함께하십시오.

다른 사람들은 고려 사항을 논의했습니다.

아마도 중요한 차이점은 Windows 프로세스에서는 스레드에 비해 무겁고 비싸고 Linux에서는 차이가 훨씬 작기 때문에 방정식의 균형이 다른 점입니다.

옛날 옛적에 유닉스가 있었고이 오래된 유닉스에는 프로세스에 대한 오버 헤드가 많았 기 때문에 일부 영리한 사람들은 스레드를 만들었습니다.이 스레드는 부모 프로세스와 동일한 주소 공간을 공유하고 컨텍스트가 줄어 들었습니다. 컨텍스트 전환을보다 효율적으로 만드는 스위치입니다.

현대 리눅스 (2.6.x)에서는 스레드와 비교하여 프로세스의 컨텍스트 전환간에 성능에 큰 차이가 없습니다 (MMU 만 스레드에 추가됨). 공유 주소 공간에 문제가 있습니다. 이는 스레드의 잘못된 포인터가 상위 프로세스의 메모리 나 동일한 주소 공간 내의 다른 스레드를 손상시킬 수 있음을 의미합니다.

프로세스는 MMU에 의해 보호되므로 잘못된 포인터는 신호 11 만 발생하고 손상되지 않습니다.

일반적으로 프로세스 (Linux의 컨텍스트 스위치 오버 헤드는 아니지만 MMU로 인한 메모리 보호)를 사용하지만 실시간 스케줄러 클래스가 필요한 경우 pthread는 다른 차 한잔입니다.

Linux에서 스레드가 그렇게 큰 성능 향상을 가져 온다고 생각하는 이유는 무엇입니까? 이것에 대한 데이터가 있습니까, 아니면 단지 신화입니까?

당신의 작업은 얼마나 밀접하게 결합되어 있습니까?

그들이 서로 독립적으로 살 수 있다면 과정을 사용하십시오. 서로 의존하는 경우 스레드를 사용하십시오. 이렇게하면 다른 작업의 작동을 방해하지 않고 나쁜 프로세스를 종료하고 다시 시작할 수 있습니다.

설상가상으로, thread-local storage 및 Unix 공유 메모리와 같은 것이 있습니다.

스레드 로컬 저장소를 사용하면 각 스레드가 별도의 전역 개체 인스턴스를 가질 수 있습니다. 내가 사용한 유일한 시간은 RTOS에서 실행되는 응용 프로그램 코드를 위해 Linux / windows에서 에뮬레이션 환경을 만들 때였습니다. RTOS에서 각 작업은 자체 주소 공간이있는 프로세스 였고 에뮬레이션 환경에서 각 작업은 스레드 (공유 주소 공간이있는 스레드)였습니다. 싱글 톤과 같은 것에 TLS를 사용함으로써 우리는 '실제'RTOS 환경에서와 같이 각 스레드에 대해 별도의 인스턴스를 가질 수있었습니다.

공유 메모리는 여러 프로세스가 동일한 메모리에 액세스 할 때 성능 이점을 제공하지만 프로세스를 올바르게 동기화해야하는 비용 / 위험이 있습니다. 이를 수행하는 한 가지 방법은 하나의 프로세스가 공유 메모리에 데이터 구조를 작성한 다음 기존의 프로세스 간 통신 (명명 된 파이프)을 통해 해당 구조에 핸들을 보내는 것입니다.

LINUX와의 최근 작업에서 알아야 할 것은 라이브러리입니다. 스레드를 사용하는 경우 여러 스레드에서 사용할 수있는 라이브러리가 스레드로부터 안전해야합니다. 이로 인해 몇 번 화상을 입었습니다. 특히 libxml2는 스레드로부터 안전하지 않습니다. 스레드 안전으로 컴파일 할 수 있지만 적성 설치로 얻을 수있는 것은 아닙니다.

당신이 듣고있는 것에 동의해야합니다. 클러스터 xhpl등 을 벤치마킹하면 스레드보다 프로세스 성능이 항상 향상됩니다.</anecdote>

쓰레드 / 프로세스 사이의 결정은 당신이 무엇을 사용할 것인지에 따라 약간 다릅니다. 프로세스의 이점 중 하나는 PID가 있고 상위를 종료하지 않고도 종료 될 수 있다는 것입니다.

웹 서버의 실제 예를 들어, 아파치 1.3은 여러 프로세스 만 지원하는 데 사용되었지만 2.0 에서는 추상화 를 추가 하여 둘 중 하나를 전환 할 수있었습니다. 댓글이 보인다 하는 프로세스가 더 강력하지만 조금 줄 수있는 스레드가 더 나은 성능을 비트 (프로세스의 성능 짜증 창을 제외하고는 스레드를 사용하고자하는) 것에 동의합니다.

대부분의 경우 스레드보다 프로세스를 선호합니다. 스레드는 상대적으로 작은 작업 (프로세스 오버 헤드 >> 분할 된 각 작업 단위에 걸린 시간)이 있고 이들간에 메모리 공유가 필요한 경우 유용 할 수 있습니다. 큰 배열을 생각하십시오. 또한 (주제) CPU 사용률이 100 % 이상인 경우 멀티 스레딩 또는 처리의 이점이 없습니다. (사실 악화 될 것입니다)

스레드-> 스레드는 메모리 공간을 공유하며 CPU의 추상화이며 경량입니다. 프로세스-> 프로세스에는 자체 메모리 공간이 있으며 컴퓨터의 추상화입니다. 작업을 병렬화하려면 CPU를 추상화해야합니다. 그러나 스레드보다 프로세스를 사용하는 이점은 보안, 안정성이며 스레드는 프로세스보다 메모리를 적게 사용하고 대기 시간을 줄입니다. 웹과 관련한 예로 크롬과 파이어 폭스가 있습니다. Chrome의 경우 각 탭은 새로운 프로세스이므로 Chrome의 메모리 사용량은 firefox보다 높으며 제공된 보안 및 안정성은 firefox보다 좋습니다. 크롬이 제공하는 보안은 각 탭이 새로운 프로세스이므로 다른 탭이 주어진 프로세스의 메모리 공간으로 스누핑 할 수 없기 때문에 더 좋습니다.

모든 사람이 귀하의 질문에 응답하여 훌륭한 일을했다고 생각합니다. 커널의 맥락에서 이전 응답 중 일부를 명확히하고 요약하기 위해 Linux의 스레드 대 프로세스에 대한 추가 정보를 추가하고 있습니다. 그래서 내 대답은 Linux의 커널 특정 코드와 관련이 있습니다. Linux Kernel 문서에 따르면 스레드가 프로세스와 달리 공유 가상 주소 공간을 사용한다는 점을 제외하면 스레드와 프로세스는 명확하게 구분되지 않습니다 . 또한 Linux Kernel은 "task"라는 용어를 사용하여 일반적으로 프로세스 및 스레드를 나타냅니다.

"프로세스 또는 스레드를 구현하는 내부 구조가 없으며 대신 task라는 추상 스케줄링 단위를 설명하는 struct task_struct가 있습니다."

또한 Linus Torvalds에 따르면 프로세스와 스레드를 전혀 생각해서는 안되며 너무 제한적이기 때문에 유일한 차이점은 "부모 공간과 부모 주소와의 분리"또는 공유 주소 공간과 관련하여 COE 또는 실행 컨텍스트 만 다릅니다. 실제로 그는 웹 서버 예제를 사용하여 여기를 지적 합니다 (읽기를 권장합니다).

리눅스 커널 문서에 대한 완전한 신용

리소스를 공유해야하는 경우 실제로 스레드를 사용해야합니다.

또한 스레드 간 컨텍스트 전환이 프로세스 간 컨텍스트 전환보다 훨씬 저렴하다는 사실을 고려하십시오.

보안, 검증 된 성능 테스트 등 적절한 이유가없는 한 명시 적으로 별도의 프로세스를 수행 할 이유가 없습니다.