pthreads 확장에 대한 PHP 매뉴얼에서 :
pthreads는 PHP에서 사용자 랜드 멀티 스레딩을 허용하는 객체 지향 API입니다. 웹 또는 콘솔을 대상으로하는 멀티 스레드 응용 프로그램을 만드는 데 필요한 모든 도구가 포함되어 있습니다. PHP 애플리케이션은 스레드, 워커 및 스택 어블을 생성, 읽기, 쓰기, 실행 및 동기화 할 수 있습니다.
이것이 들리는 것처럼, 그것은 사실입니다. 오늘날, PHP는 그것을 시도하려는 사람들을 위해 멀티 스레드를 할 수 있습니다.
PHP4의 첫 번째 릴리스 인 2000 년 5 월 22 일, PHP는 스레드 안전 아키텍처와 함께 제공되어 멀티 스레드 SAPI (Server API) 환경에서 별도의 스레드로 여러 인터프리터의 인터프리터 인스턴스를 실행할 수 있습니다. 지난 13 년 동안이 아키텍처의 디자인은 유지되고 발전되었습니다. 그 이후로 세계에서 가장 큰 웹 사이트에서 프로덕션으로 사용되었습니다.
사용자 영역에서의 스레딩은 PHP 팀에게는 전혀 관심이 없었으며 오늘날에도 마찬가지입니다. PHP가 비즈니스를 수행하는 세계에는 이미 하드웨어 확장이라는 정의 된 확장 방법이 있다는 것을 이해해야합니다. 수년 동안 PHP가 존재하고 하드웨어는 저렴하고 저렴 해졌으며 이는 PHP 팀의 관심사가 점점 줄어 들었습니다. 저렴 해지면서 훨씬 강력 해졌습니다. 오늘날 우리의 휴대 전화 및 태블릿에는 듀얼 및 쿼드 코어 아키텍처와 많은 RAM이 있으며, 데스크탑 및 서버에는 일반적으로 8 또는 16 코어, 16 및 32 기가 바이트 RAM이 있지만 항상 2 개를 가질 수는 없습니다. 예산 내에서 두 대의 데스크톱을 사용하는 것이 우리에게는 거의 유용하지 않습니다.
또한 PHP는 프로그래머가 아닌 사람들을 위해 작성되었으며 많은 애호가들이 모국어입니다. PHP가 그렇게 쉽게 채택되는 이유는 배우고 쓰기가 쉬운 언어이기 때문입니다. 오늘날 PHP가 신뢰할 수있는 이유는 디자인에 들어가는 방대한 양의 작업과 PHP 그룹의 모든 단일 결정 때문입니다. 몇 년이 지난 후에도 신뢰성과 굉장한 위대함이 스포트라이트를 유지합니다. 라이벌이 시간이나 압력에 빠진 곳.
멀티 스레드 프로그래밍은 가장 일관성 있고 안정적인 API를 사용하더라도 생각해야 할 사항이 많으며 많은 오해가 있습니다. PHP 그룹은 사용자 랜드 멀티 스레딩이 핵심 기능이되기를 원하지 않습니다. 심각한 관심을받지 못했습니다. PHP는 모두에게 복잡하지 않아야합니다.
고려해야 할 모든 것, PHP가 프로덕션 준비 및 테스트 된 기능을 활용하여 우리가 가진 것을 최대한 활용할 수있는 수단을 제공함으로써 더 많은 것을 추가하는 것이 항상 옵션이 아니며 많은 경우 여전히 이점이 있습니다. 작업이 실제로 필요하지 않습니다.
pthreads는 사용자가 그것을 탐색하고자하는 사람들을 위해 사용자가 PHP 응용 프로그램을 멀티 스레딩 할 수있는 API를 달성합니다. API는 매우 진행중인 작업이며 베타 수준의 안정성과 완전성을 지정했습니다.
PHP가 사용하는 라이브러리 중 일부는 스레드로부터 안전하지 않다는 것은 일반적인 지식입니다. pthreads가이를 변경할 수 없으며 시도하지 않음을 프로그래머에게 분명히 알려야합니다. 그러나 인터프리터의 다른 스레드 안전 설정에서와 같이 스레드 안전 라이브러리를 사용할 수 있습니다.
pthreads는 Posix Threads (Windows에서도)를 사용합니다. 프로그래머가 만드는 것은 실제 실행 스레드이지만, 스레드가 유용하려면 PHP를 알아야 사용자 코드를 실행하고 변수를 공유하며 유용한 통신 수단을 사용할 수 있습니다 (동기화). 따라서 모든 스레드는 인터프리터 인스턴스로 작성되지만 설계 상 인터프리터는 멀티 스레드 서버 API 환경과 마찬가지로 인터프리터의 다른 모든 인스턴스와 분리되어 있습니다. pthreads는 깔끔하고 안전한 방식으로 격차를 해소하려고합니다. C의 스레드 프로그래머에 대한 많은 우려는 pthreads 프로그래머에게는 존재하지 않습니다. 설계 상 pthreads는 읽기시 복사 및 쓰기시 복사 (RAM은 저렴합니다), 따라서 두 인스턴스가 동일한 물리적 데이터를 조작하지 않습니다. 하지만 다른 스레드의 데이터에 영향을 줄 수 있습니다.
읽기에서 복사하고 쓰기에서 복사하는 이유 :
public function run() {
...
(1) $this->data = $data;
...
(2) $this->other = someOperation($this->data);
...
}
(3) echo preg_match($pattern, $replace, $thread->data);
(1) pthreads 객체 데이터 저장소에서 읽기 및 쓰기 잠금이 유지되는 동안 데이터는 메모리의 원래 위치에서 객체 저장소로 복사됩니다. pthreads는 변수의 참조 횟수를 조정하지 않으므로 Zend는 더 이상 참조가 없으면 원래 데이터를 해제 할 수 있습니다.
(2) someOperation에 대한 인수는 (1) 결과의 사본 자체가 엔진에 대해 zval 컨테이너로 다시 복사되는 저장된 원래 데이터 인 오브젝트 저장소를 참조합니다.이 경우 읽기 잠금이 유지됩니다. 오브젝트 저장소, 잠금이 해제되고 엔진이 기능을 실행할 수 있습니다. zval이 작성되면 참조 횟수는 0이며, 참조가 존재하지 않기 때문에 엔진이 조작 완료시 사본을 해제 할 수 있습니다.
(3) preg_match의 마지막 인수는 데이터 저장소를 참조하고, 읽기 잠금이 획득되고, (1)에 설정된 데이터가 다시 0의 참조 횟수로 zval에 복사됩니다. 잠금이 해제되고 preg_match에 대한 호출은 다음에서 작동합니다. 데이터 사본, 즉 그 자체가 원본 데이터의 사본.
알아야 할 사항 :
스레드 안전 데이터가 저장되는 오브젝트 저장소의 해시 테이블은
Zend가 PHP와 함께 제공 한 TsHashTable을 기반으로합니다.
오브젝트 저장소에는 읽기 및 쓰기 잠금이 있으며, TsHashTable에 대한 추가 액세스 잠금이 제공되므로 필요한 경우 (var_dump / print_r, PHP 엔진이 참조하고자하는 속성에 직접 액세스) pthread가 TsHashTable을 조작 할 수 있습니다. 정의 된 API 외부.
잠금은 복사가 수행되는 동안, 사본이 만들어 졌을 때 잠금이 해제 된 상태에서 합리적인 순서로만 유지됩니다.
이것은 다음을 의미합니다.
쓰기가 발생하면 읽기 및 쓰기 잠금뿐만 아니라 추가 액세스 잠금이 유지됩니다. 테이블 자체가 잠겨 있으므로 다른 컨텍스트가 잠금, 읽기, 쓰기 또는 영향을 줄 수있는 방법이 없습니다.
읽기가 발생하면 읽기 잠금이 유지 될뿐만 아니라 추가 액세스 잠금도 다시 테이블이 잠 깁니다.
두 컨텍스트가 오브젝트 저장소에서 동일한 데이터에 물리적으로 또는 동시에 액세스 할 수는 없지만 참조를 사용하여 컨텍스트에서 작성된 쓰기는 참조가있는 컨텍스트에서 읽은 데이터에 영향을줍니다.
이것은 아무 것도 공유하지 않으며 존재하는 유일한 방법은 공존합니다. 약간 정통한 사람들은 여기에 많은 복사가 진행되고 있으며 이것이 좋은지 궁금해 할 것입니다. 다이나믹 런타임에서 상당히 많은 복사가 진행됩니다. 다이나믹 언어의 다이나믹입니다. pthreads는 객체의 수준에서 구현됩니다. 하나의 객체를 제대로 제어 할 수는 있지만 메소드 (프로그래머가 실행하는 코드)에는 잠금 및 복사가없는 다른 컨텍스트가 있으며 로컬 메소드 범위가 있습니다. pthreads 객체의 경우 객체 범위는 컨텍스트간에 데이터를 공유하는 방법으로 취급되어야합니다. 이를 염두에두고 필요한 경우가 아니라면 객체 저장소를 잠그지 않는 기술을 채택 할 수 있습니다.
PHP에 사용할 수있는 대부분의 라이브러리와 확장 프로그램은 타사를 중심으로하는 씬 래퍼이며 PHP 핵심 기능은 어느 정도 동일합니다. pthreads는 Posix Threads의 얇은 래퍼가 아닙니다. Posix Threads를 기반으로 한 스레딩 API입니다. PHP에서 스레드를 구현할 때 사용자가 이해하지 못하거나 사용할 수 없다는 점은 없습니다. 뮤텍스가 무엇인지 모르는 사람이 기술과 자원 측면에서 자신이 가진 모든 것을 이용할 수 없어야 할 이유는 없습니다. 객체는 객체처럼 작동하지만 두 컨텍스트가 충돌 할 때마다 pthread는 안정성과 안전성을 제공합니다.
자바에서 일한 사람은 pthreads 객체와 자바의 스레딩 사이의 유사점을 보게 될 것입니다. 동일한 사람들은 ConcurrentModificationException이라는 오류를 보았을 것입니다. 두 개의 스레드가 동일한 물리적 데이터를 쓰면 Java 런타임에 의해 발생한 오류로 들립니다. 동시에. 나는 그것이 존재하는 이유를 이해하지만 런타임은 사용자가 안전을 얻을 수있는 정확한 시간에만 동시성을 감지 할 수 있다는 사실과 함께 저렴한 리소스로 값을 낮춰서 선택합니다. 실행 및 데이터 액세스를 관리하는 대신 런타임시 치명적인 오류가 발생합니다.
그런 바보 같은 오류는 pthreads에서 발생하지 않으며 API는 스레딩을 안정적으로 만들고 가능한 한 호환되도록 작성되었습니다.
멀티 스레딩은 새로운 데이터베이스를 사용하는 것과 다르므로 매뉴얼의 모든 단어와 pthread와 함께 제공되는 예제에주의를 기울여야합니다.
마지막으로 PHP 매뉴얼에서 :
pthreads는 꽤 좋은 결과를 얻은 실험이었습니다. 제한 사항이나 기능은 언제든지 변경 될 수 있습니다. 그것이 실험의 본질입니다. 구현에 의해 종종 부과되는 한계는 정당한 이유가 있습니다. pthreads의 목적은 모든 레벨에서 PHP의 멀티 태스킹에 유용한 솔루션을 제공하는 것입니다. pthread가 실행되는 환경에서는 안정적인 환경을 제공하기 위해 몇 가지 제한 사항이 필요합니다.
pcntl_fork()아파치에서 호출 하면 이것이 ( ) 작동하는지 아는 사람이 있습니까?