Dari manual PHP untuk ekstensi pthreads :
pthreads adalah Object Orientated API yang memungkinkan pengguna-lahan multi-threading di PHP. Ini mencakup semua alat yang Anda butuhkan untuk membuat aplikasi multi-utas yang ditargetkan di Web atau Konsol. Aplikasi PHP dapat membuat, membaca, menulis, mengeksekusi, dan menyinkronkan dengan Threads, Workers and Stackables.
Tidak bisa dipercaya kedengarannya, ini sepenuhnya benar. Hari ini, PHP dapat multi-utas bagi mereka yang ingin mencobanya.
Rilis pertama PHP4, 22 Mei 2000, PHP dikirim dengan arsitektur thread thread - cara untuk mengeksekusi beberapa contoh penerjemahnya di utas terpisah di lingkungan SAPI (Server API) multi-utas. Selama 13 tahun terakhir, desain arsitektur ini telah dipertahankan dan maju: Ini telah digunakan dalam produksi di situs web terbesar di dunia sejak itu.
Threading di tanah pengguna tidak pernah menjadi perhatian bagi tim PHP, dan tetap seperti sekarang ini. Anda harus memahami bahwa di dunia di mana PHP menjalankan bisnisnya, sudah ada metode penskalaan yang ditentukan - tambahkan perangkat keras. Selama bertahun-tahun PHP telah ada, perangkat keras menjadi lebih murah dan lebih murah sehingga ini menjadi kurang dan kurang menjadi perhatian bagi tim PHP. Meskipun semakin murah, ia juga menjadi jauh lebih kuat; hari ini, ponsel dan tablet kami memiliki arsitektur dual dan quad core dan banyak RAM yang harus disertakan, desktop dan server kami umumnya memiliki 8 atau 16 core, 16 dan 32 gigabytes RAM, meskipun kami mungkin tidak selalu dapat memiliki dua sesuai anggaran dan memiliki dua desktop jarang berguna bagi kebanyakan dari kita.
Selain itu, PHP ditulis untuk non-programmer, itu adalah banyak penggemar bahasa asli. Alasan PHP sangat mudah diadopsi adalah karena itu adalah bahasa yang mudah dipelajari dan ditulis. Alasan PHP sangat dapat diandalkan hari ini adalah karena banyaknya pekerjaan yang masuk ke dalam desain itu, dan setiap keputusan dibuat oleh grup PHP. Ini keandalan dan kebesaran semata-mata menyimpannya dalam sorotan, setelah bertahun-tahun; di mana saingannya jatuh ke waktu atau tekanan.
Pemrograman multi-utas tidak mudah untuk sebagian besar, bahkan dengan API yang paling koheren dan dapat diandalkan, ada beberapa hal yang berbeda untuk dipikirkan, dan banyak kesalahpahaman. Grup PHP tidak berharap pengguna darat multi-threading menjadi fitur inti, tidak pernah diberi perhatian serius - dan memang demikian. PHP seharusnya tidak rumit, untuk semua orang.
Semua hal dipertimbangkan, masih ada manfaat yang bisa didapat dari memungkinkan PHP untuk memanfaatkan fitur siap produksi dan teruji untuk memungkinkan cara memaksimalkan apa yang kita miliki, ketika menambahkan lebih banyak tidak selalu menjadi pilihan, dan banyak tugas tidak pernah benar-benar dibutuhkan.
pthreads mencapai, bagi mereka yang ingin menjelajahinya, sebuah API yang memungkinkan pengguna untuk aplikasi PHP multi-thread. Itu API sangat banyak pekerjaan dalam proses, dan ditunjuk tingkat beta stabilitas dan kelengkapan.
Sudah menjadi rahasia umum bahwa beberapa perpustakaan menggunakan PHP tidak aman thread, itu harus jelas kepada programmer bahwa pthreads tidak dapat mengubah ini, dan tidak mencoba untuk mencoba. Namun, perpustakaan apa pun yang aman utas dapat digunakan, seperti dalam pengaturan utas lainnya dari penerjemah.
pthreads menggunakan Posix Threads (bahkan di Windows), apa yang dibuat oleh programmer adalah utas eksekusi nyata, tetapi agar utas tersebut bermanfaat, mereka harus menyadari PHP - mampu mengeksekusi kode pengguna, berbagi variabel, dan memungkinkan alat komunikasi yang berguna (sinkronisasi). Jadi setiap utas dibuat dengan instance dari juru bahasa, tetapi dengan desain, juru itu diisolasi dari semua contoh lain dari juru bahasa - seperti lingkungan Server API multi-utas. pthreads berupaya menjembatani kesenjangan dengan cara yang waras dan aman. Banyak kekhawatiran dari programmer threads di C hanya tidak ada untuk programmer dari pthreads, secara desain, pthreads adalah copy pada read dan copy on write (RAM murah), jadi tidak ada dua contoh yang pernah memanipulasi data fisik yang sama , tetapi keduanya dapat memengaruhi data di utas lainnya.
Mengapa menyalin saat dibaca dan menyalin saat menulis:
public function run() {
...
(1) $this->data = $data;
...
(2) $this->other = someOperation($this->data);
...
}
(3) echo preg_match($pattern, $replace, $thread->data);
(1) Ketika kunci baca dan tulis ditahan pada penyimpanan data objek pthreads, data disalin dari lokasi aslinya dalam memori ke penyimpanan objek. pthreads tidak menyesuaikan refcount variabel, Zend dapat membebaskan data asli jika tidak ada referensi lebih lanjut.
(2) Argumen untuk beberapa operasi referensi objek menyimpan, data asli yang disimpan, yang itu sendiri merupakan salinan hasil (1), disalin lagi untuk mesin ke dalam wadah zval, sementara ini terjadi kunci baca diadakan pada toko objek, kunci dilepaskan dan mesin dapat menjalankan fungsi. Ketika zval dibuat, ia memiliki penghitungan ulang 0, memungkinkan mesin untuk membebaskan salinan pada selesainya operasi, karena tidak ada referensi lain untuk itu ada.
(3) Argumen terakhir untuk preg_match referensi menyimpan data, kunci baca diperoleh, set data dalam (1) disalin ke zval, lagi dengan refcount dari 0. Kunci dilepaskan, Panggilan untuk preg_match beroperasi pada salinan data, itu sendiri merupakan salinan dari data asli.
Hal yang perlu diketahui:
Tabel hash toko objek di mana data disimpan, aman thread,
didasarkan pada TsHashTable dikirimkan dengan PHP, oleh Zend.
Toko objek memiliki kunci baca dan tulis, kunci akses tambahan disediakan untuk TsHashTable sehingga jika diperlukan (dan memang diperlukan, var_dump / print_r, akses langsung ke properti ketika mesin PHP ingin merujuknya) pthreads dapat memanipulasi TsHashTable di luar API yang ditentukan.
Kunci hanya ditahan saat operasi penyalinan terjadi, ketika salinan telah dibuat kunci dilepaskan, dalam urutan yang masuk akal.
Ini berarti:
Ketika menulis terjadi, tidak hanya kunci baca dan tulis ditahan, tetapi kunci akses tambahan. Tabel itu sendiri dikunci, tidak mungkin konteks lain dapat mengunci, membaca, menulis atau memengaruhinya.
Ketika pembacaan terjadi, tidak hanya kunci baca dipegang, tetapi kunci akses tambahan juga, lagi meja dikunci.
Tidak ada dua konteks yang secara fisik maupun bersamaan dapat mengakses data yang sama dari penyimpanan objek, tetapi penulisan yang dibuat dalam konteks apa pun dengan referensi akan memengaruhi data yang dibaca dalam konteks apa pun dengan referensi.
Ini tidak dibagikan arsitektur apa pun dan satu-satunya cara untuk ada adalah berdampingan. Mereka yang sedikit mengerti akan melihat itu, ada banyak penyalinan yang terjadi di sini, dan mereka akan bertanya-tanya apakah itu hal yang baik. Cukup banyak penyalinan berlangsung dalam runtime dinamis, itulah dinamika bahasa dinamis. pthreads diimplementasikan pada level objek, karena kontrol yang baik dapat diperoleh atas satu objek, tetapi metode - kode yang dieksekusi programmer - memiliki konteks lain, bebas dari penguncian dan salinan - lingkup metode lokal. Cakupan objek dalam kasus objek pthreads harus diperlakukan sebagai cara untuk berbagi data di antara konteks, yaitu tujuannya. Dengan pemikiran ini Anda dapat mengadopsi teknik untuk menghindari mengunci toko objek kecuali itu perlu,
Sebagian besar perpustakaan dan ekstensi yang tersedia untuk PHP adalah pembungkus tipis di sekitar pihak ke-3, fungsionalitas inti PHP pada tingkat yang sama. pthreads bukan pembungkus tipis di sekitar Posix Threads; itu adalah threading API berdasarkan Posix Threads. Tidak ada gunanya mengimplementasikan Threads di PHP yang pengguna tidak mengerti atau tidak bisa menggunakannya. Tidak ada alasan bahwa seseorang yang tidak memiliki pengetahuan tentang apa itu mutex atau tidak seharusnya tidak dapat mengambil keuntungan dari semua yang mereka miliki, baik dalam hal keterampilan, dan sumber daya. Objek berfungsi seperti objek, tetapi di mana pun dua konteks akan bertabrakan, pthreads memberikan stabilitas dan keamanan.
Siapa pun yang telah bekerja di java akan melihat kesamaan antara objek pthreads dan threading di java, orang-orang yang sama tidak akan ragu melihat kesalahan yang disebut ConcurrentModificationException - karena terdengar kesalahan yang ditimbulkan oleh runtime java jika dua utas menulis data fisik yang sama secara bersamaan. Saya mengerti mengapa itu ada, tetapi membingungkan saya bahwa dengan sumber daya semurah mereka, ditambah dengan fakta runtime mampu mendeteksi konkurensi pada waktu yang tepat dan hanya keamanan yang dapat dicapai untuk pengguna, yang ia pilih untuk melempar kesalahan yang mungkin fatal saat runtime daripada mengelola eksekusi dan akses ke data.
Tidak ada kesalahan bodoh yang akan dipancarkan oleh pthreads, API ditulis untuk membuat threading stabil, dan kompatibel mungkin, saya percaya.
Multi-threading tidak seperti menggunakan database baru, perhatian harus diberikan kepada setiap kata dalam manual dan contoh yang dikirimkan dengan pthreads.
Terakhir, dari manual PHP:
pthreads dulu adalah eksperimen dengan hasil yang cukup bagus. Setiap batasan atau fitur dapat berubah sewaktu-waktu; itulah sifat eksperimen. Keterbatasan - sering dipaksakan oleh implementasi - ada karena alasan yang baik; Tujuan dari pthreads adalah untuk memberikan solusi yang dapat digunakan untuk multi-tasking di PHP di level apa pun. Dalam lingkungan yang dijalankan oleh pthread, beberapa pembatasan dan pembatasan diperlukan untuk menyediakan lingkungan yang stabil.
pcntl_fork()) akan berfungsi jika dipanggil dari Apache?