Artikel ini akan menceritakan tentang pengalaman menggunakan pendekatan aktor dalam satu proyek yang menarik dari sistem kontrol otomatis untuk teater. Ini persis kesan penggunaan, tidak lebih.
Baru-baru ini, saya dapat berpartisipasi dalam satu tugas yang sangat menarik - modernisasi, tetapi pada kenyataannya - pengembangan sistem kontrol otomatis baru untuk mengangkat rak untuk salah satu teater.
Sebuah teater modern (jika itu besar) adalah organisasi yang agak rumit. Banyak orang, peralatan dan berbagai sistem terlibat di dalamnya. Salah satu sistem tersebut adalah sistem kontrol untuk "menaikkan dan menurunkan" pemandangan di atas panggung. Pertunjukan modern, dan lebih banyak opera dan balet, menjadi semakin jenuh dengan sarana teknis setiap tahun. Ini menggunakan banyak pemandangan kompleks dan gerakan mereka selama aksi. Pemandangan ini secara aktif digunakan dalam rencana penyutradaraan, memperluas makna dari apa yang terjadi dan bahkan "memainkan peran pendukung Anda sendiri"). Secara umum, sangat menarik untuk berkenalan dengan kehidupan di belakang panggung teater dan mencari tahu apa yang terjadi di sana selama pertunjukan. Bagaimanapun, pemirsa biasa hanya melihat apa yang terjadi di panggung.
Tetapi artikel ini masih bersifat teknis dan di dalamnya saya ingin berbagi pengalaman menggunakan pendekatan aktor untuk menerapkan manajemen. Dan juga berbagi pengalaman menggunakan salah satu dari beberapa kerangka kerja aktor C ++ - sobjectizer .
Kenapa tepatnya dia? Kami telah mengawasinya sejak lama. Ada artikel tentang habr, ia memiliki dokumentasi rinci yang sangat baik dengan contoh-contoh. Proyek ini cukup matang. Melihat sekilas pada contoh menunjukkan bahwa pengembang beroperasi dengan konsep "akrab" (negara, timer, peristiwa), yaitu masalah besar tidak diharapkan dengan pemahaman dan penguasaan, untuk digunakan dalam proyek kami. Dan ya, yang penting, pengembangnya memadai dan ramah, siap membantu dengan saran (dalam bahasa Rusia) . Jadi kami memutuskan untuk mencoba ...
Apa yang kita lakukan
Jadi, seperti apa "objek kontrol" kita? Sistem lift shtanketovy - ini adalah 62 shankets (pipa logam) di seluruh lebar panggung yang tergantung di atas adegan ini, kira-kira setiap 30 - 40 cm dari tepi panggung secara mendalam. Shankets itu sendiri tergantung pada tali dan dapat naik atau turun ke panggung (gerakan vertikal). Dalam setiap pertunjukan (atau opera atau balet), bagian dari bait digunakan untuk dekorasi. Pemandangan digantung pada mereka dan dipindahkan (jika naskah mengharuskannya) selama aksi. Gerakan itu sendiri dilakukan atas perintah operator (mereka memiliki panel kontrol khusus) menggunakan sistem "mesin - kabel - penyeimbang" (hampir sama dengan lift di rumah). Mesin terletak di tepi panggung (pada beberapa tingkatan), sehingga tidak terlihat oleh penonton. Semua motor dibagi menjadi 8 kelompok dan masing-masing kelompok memiliki tiga konverter frekuensi (IF). Di setiap kelompok, tiga motor dapat diaktifkan secara bersamaan, masing-masing terhubung ke inverter sendiri. Secara total, kami memiliki sistem 62 mesin dan 24 inverter, yang harus kami kontrol.
Tugas kami adalah mengembangkan antarmuka operator untuk mengelola ekonomi ini, serta mengimplementasikan algoritma manajemen. Sistem ini mencakup tiga pos kontrol. Dua pos kontrol terletak tepat di atas panggung dan satu pos terletak di ruang mesin (di mana lemari kontrol berada) dan dirancang untuk memantau pekerjaan bagi tukang listrik yang sedang bertugas. Di kabinet kontrol ada pengendali yang menjalankan perintah, mengendalikan PWM, memasok daya ke motor, melacak posisi betis. Pada dua remote atas adalah monitor, unit sistem di mana algoritma kontrol dan trackball berputar sebagai "mouse". Jaringan Ethernet digunakan antara panel kontrol. Setiap kabinet kontrol memiliki saluran RS485 (mis. 8 saluran) dari masing-masing dari dua panel kontrol. Manajemen dapat dilakukan secara bersamaan dari kedua remote (yang berada di atas panggung), tetapi pada saat yang sama hanya satu remote (ditunjuk oleh operator sebagai operator utama) yang bertukar dengan kabinet, konsol kedua saat ini dianggap sebagai cadangan dan pertukaran dinonaktifkan di atasnya.
Dan di sini para aktor
Dari sudut pandang algoritma, seluruh sistem dibangun berdasarkan peristiwa. Entah ini adalah beberapa perubahan pada sensor, atau tindakan operator, atau timbulnya waktu (timer). Dan algoritma seperti itu ditempatkan dengan sangat baik oleh sistem aktor yang memproses peristiwa yang masuk, membentuk semacam respons, dan semua ini tergantung pada keadaan mereka. Di sobjectizer, semua mekanisme ini keluar dari kotak. Prinsip-prinsip utama yang menjadi dasar sistem semacam itu dapat dikaitkan: interaksi antara aktor terjadi melalui pesan, aktor dapat memiliki negara dan bergerak di antara mereka, di setiap negara aktor hanya memproses pesan-pesan yang menarik baginya saat ini. Menariknya, dalam sobjectizer, bekerja dengan aktor secara konseptual terpisah dari bekerja dengan alur kerja. Yaitu Anda dapat menggambarkan aktor yang Anda butuhkan, mewujudkan logika mereka, mewujudkan interaksi mereka melalui pesan. Tetapi kemudian secara terpisah memecahkan masalah mengalokasikan utas (sumber daya) untuk pekerjaan mereka. Ini dipastikan oleh apa yang disebut "dispatcher" yang bertanggung jawab atas kebijakan khusus untuk bekerja dengan utas. Misalnya, ada dispatcher yang mengalokasikan utas terpisah untuk setiap aktor untuk bekerja dengannya, ada dispatcher yang menyediakan kumpulan utas (mis. Mungkin ada lebih banyak aktor daripada utas) dengan kemampuan untuk mengatur jumlah maksimum utas, ada dispatcher yang mengalokasikan satu utas untuk semua. Kehadiran operator menyediakan mekanisme yang sangat fleksibel untuk mengatur sistem aktor agar sesuai dengan kebutuhan Anda. Anda dapat menggabungkan kelompok aktor untuk bekerja dengan salah satu operator, sementara mengubah satu jenis operator ke yang lain, ini pada dasarnya mengubah satu baris kode. Menurut penulis kerangka kerja, menulis operator unik Anda juga tidak sulit. Ini tidak diperlukan dalam proyek kami, karena semua yang kami butuhkan sudah ada di sobjectizer.
Fitur menarik lainnya adalah hadirnya konsep "kerja sama" aktor. Kerjasama adalah sekelompok aktor yang dapat semua ada atau dihancurkan (atau tidak diluncurkan) jika setidaknya satu aktor dalam kerjasama tidak dapat mulai bekerja atau menyelesaikan. Saya bahkan tidak takut untuk memberikan analogi seperti itu ( meskipun berasal dari "opera" lain ) bahwa konsep "kerja sama" adalah seperti konsep "perapian" di Kubernet yang sekarang modis, hanya terlihat di sobjectizer, muncul lebih awal ...
Pada saat penciptaan, masing-masing aktor termasuk dalam kerja sama (kerja sama dapat terdiri dari satu aktor), menjadi melekat pada satu atau operator lain dan mulai bekerja. Pada saat yang sama, aktor (dan kerja sama) dapat (dengan mudah) dibuat secara dinamis dalam jumlah besar, dan seperti yang dijanjikan pengembang, itu tidak mahal. Semua aktor bertukar di antara mereka sendiri melalui " kotak surat " (mbox). Ini juga konsep yang cukup menarik dan kuat di sobjectizer. Ini menyediakan mekanisme yang sangat fleksibel untuk memproses pesan masuk. Pertama, lebih dari satu penerima mungkin bersembunyi di balik kotak. Ini benar-benar sangat nyaman. Misalnya, sebuah kotak dibuat di mana peristiwa dari sensor eksternal diterima dan masing-masing aktor berlangganan acara yang menarik baginya. Ini memberikan gaya operasi "terbitkan / berlangganan". Kedua, para pengembang telah memberikan kesempatan untuk secara relatif mudah membuat implementasi kotak surat mereka sendiri yang dapat melakukan pra-proses pesan masuk (misalnya, entah bagaimana memfilternya atau mendistribusikannya dengan cara khusus di antara konsumen). Selain itu, setiap aktor memiliki kotak suratnya sendiri dan bahkan dapat mengirim "tautan" ke sana dalam pesan ke aktor lain, misalnya, sehingga mereka dapat mengirim semacam pemberitahuan sebagai tanggapan balik.
Dalam proyek kami, untuk memastikan kemandirian kelompok mesin di antara mereka sendiri, serta untuk memastikan pengoperasian mesin yang “tidak sinkron” dalam kelompok, semua objek kontrol dibagi menjadi 8 kelompok (sesuai dengan jumlah kabinet kontrol), yang masing-masing memiliki tiga pekerja flow (karena tidak lebih dari tiga mesin dapat beroperasi dalam satu grup sekaligus).
Juga harus dikatakan bahwa sobjectizer (dalam versi saat ini 5.5) tidak mengandung interprocess dan mekanisme interaksi jaringan dan menyerahkan bagian ini kepada pengembang. Para penulis melakukan ini dengan cukup sengaja , sehingga kerangka kerjanya lebih “mudah”. Selain itu, mekanisme interaksi jaringan "sekali" ada di versi sebelumnya, tetapi dikeluarkan. Namun, ini tidak menimbulkan ketidaknyamanan, karena memang interaksi jaringan sangat tergantung pada tugas yang diselesaikan, protokol pertukaran yang digunakan, dll. Di sini, implementasi universal tidak dapat optimal untuk semua kasus.
Dalam kasus kami, untuk komunikasi jaringan dan antarproses, kami menggunakan salah satu perkembangan lama kami - perpustakaan libuniset2 . Akibatnya, arsitektur sistem kami terlihat seperti ini:
- libuniset menyediakan komunikasi jaringan dan antar proses (berdasarkan pada sensor)
- sobjectizer menyediakan pembuatan sistem aktor yang berinteraksi satu sama lain (dalam ruang alamat yang sama) menerapkan algoritma kontrol.
Jadi, izinkan saya mengingatkan Anda, kami memiliki 62 mesin. Setiap motor dapat dihubungkan ke inverter, dudukan yang sesuai dapat diberikan koordinat tempat Anda harus tiba dan kecepatan Anda harus bergerak. Selain itu, mesin memiliki kondisi berikut:
- siap berangkat
- terhubung
- running (berputar)
- kecelakaan
- koneksi (keadaan sementara)
- shutdown (keadaan sementara)
Akibatnya, setiap "mesin" diwakili dalam sistem oleh aktor yang mengimplementasikan logika transisi antar negara, memproses peristiwa dari sensor, dan mengeluarkan perintah kontrol. Di sobjectizer, aktor dibuat dengan mudah, cukup mewarisi kelas Anda dari kelas dasar so_5 :: agent_t. Dalam hal ini, konstruktor harus menerima apa yang disebut :: so_5 :: context_t konteks sebagai argumen pertama, argumen yang tersisa ditentukan oleh kebutuhan pengembang.
class Drive_A: public so_5::agent_t { public: Drive_A( context_t ctx, ... ); ... }
Karena artikel ini tidak mendidik, jadi saya tidak akan memberikan di sini teks-teks terperinci dari deskripsi kelas atau metode. Artikel ini hanya ingin menunjukkan betapa mudahnya (dalam beberapa baris) dengan bantuan sobjectizer semua ini diterapkan. Biarkan saya mengingatkan Anda bahwa proyek ini memiliki dokumentasi detail yang sangat baik, dengan banyak contoh berbeda.
Dan apa "negara" aktor-aktor ini? Apa yang kamu bicarakan
Penggunaan status dan transisi di antara mereka untuk ACS umumnya merupakan topik asli. "Konsep" ini sangat cocok dalam penanganan acara. Dalam sobjectizer, konsep ini didukung di tingkat API. Dalam kelas aktor, negara cukup mudah dinyatakan
class Drive_A final: public so_5::agent_t { public: Drive_A( context_t ctx, ... ); virtual ~Drive_A();
dan selanjutnya, untuk setiap negara bagian, pengembang menentukan penangan yang diperlukan. Seringkali, beberapa tindakan diperlukan saat memasuki suatu negara dan ketika keluar. Ini juga disediakan untuk di sobjectizer, Anda juga dapat dengan mudah menentukan penangan Anda untuk acara-acara ini ("entri negara", "keluar dari negara"). Dirasakan bahwa para pengembang di masa lalu memiliki pengalaman ACS-shny yang luas ...
Penangan acara
Penangan acara, di sinilah logika aplikasi Anda diimplementasikan. Seperti disebutkan di atas, langganan dibuat ke kotak surat tertentu dan untuk keadaan aktor tertentu. Jika seorang aktor tidak memiliki status yang dinyatakan secara eksplisit dalam kode, maka ia secara implisit dalam status khusus "default_state". Di negara bagian yang berbeda, Anda dapat menentukan penangan yang berbeda untuk acara yang sama. Jika Anda tidak menentukan penangan acara apa pun di kotak surat ini, itu hanya akan diabaikan (mis., Itu tidak akan ada untuk aktor).
Sintaks untuk mendefinisikan handler sangat sederhana. Cukup untuk menunjukkan fungsi Anda. Tidak ada tipe atau argumen templat yang diperlukan. Semuanya disimpulkan secara otomatis dari definisi fungsi. Sebagai contoh:
so_subscribe(drv->so_mbox()) .in(st_base) .event( &Drive_A::on_get_info ) .event( &Drive_A::on_control ) .event( &Drive_A::off_control );
Berikut adalah contoh berlangganan acara di kotak tertentu untuk status st_base. Menariknya, dalam contoh ini, st_base adalah keadaan dasar untuk negara bagian lain, dan karenanya langganan ini akan berlaku untuk semua negara bagian yang “diwarisi” dari st_base. Pendekatan ini memungkinkan Anda untuk menyingkirkan "salin-tempel" untuk menentukan penangan yang sama untuk negara bagian yang berbeda. Pada saat yang sama, dalam keadaan tertentu, Anda dapat mengesampingkan penangan yang ditentukan atau "menonaktifkannya" (tekan).
Ada cara lain untuk mendefinisikan penangan. Ini adalah definisi langsung dari fungsi lambda. Ini adalah cara yang sangat mudah, karena seringkali penangan adalah fungsi pendek dalam beberapa tindakan, mengirim sesuatu kepada seseorang atau mengganti status.
so_subscribe(drv->so_mbox()) .in(st_disconnecting) .event([this](const msg_disconnected_t& m) { ... st_off.activate(); }) .event([this]( const msg_failure_t& m ) { ... st_protection.activate(); });
Pada awalnya, sintaks ini tampaknya rumit. Tetapi hanya dalam beberapa hari perkembangan aktif, Anda terbiasa dan bahkan mulai menyukainya. Karena seluruh logika aktor bekerja dalam satu keadaan atau yang lain dapat masuk dalam kode yang agak pendek dan semuanya akan berada di depan mata Anda. Misalnya, dalam contoh yang ditunjukkan, dalam keadaan terputus (st_disconnecting), baik transisi ke keadaan terputus (st_off.) Atau keadaan perlindungan (st_protection) terjadi jika pesan tentang beberapa jenis kegagalan terjadi. Kode semacam itu cukup mudah dibaca.
Ngomong-ngomong, untuk kasus-kasus sederhana ketika suatu peristiwa hanya perlu masuk ke beberapa keadaan, ada sintaks yang bahkan lebih pendek:
auto mbox = drv->so_mbox(); st_off .just_switch_to<msg_connected_t>(mbox, st_connected) .just_switch_to<msg_failure_t>(mbox, st_protection) .just_switch_to<msg_on_limit_t>(mbox, st_protection) .just_switch_to<msg_on_t>(mbox, st_on);
Manajemen
Bagaimana cara pengelolaan semua ekonomi ini bekerja? Seperti disebutkan di atas, dua kendali jarak jauh disediakan untuk kendali langsung pergerakan shtankets. Pada setiap kendali jarak jauh terdapat monitor, manipulator (trackball) dan panggilan cepat (selain "komputer" yang tersembunyi di kendali jarak jauh tempat semuanya berputar dan tumpukan semua jenis konverter). Sistem ini memiliki beberapa mode untuk mengendalikan pergerakan shtankets. Manual dan "mode skrip". Tentang "mode skenario" akan dibahas lebih lanjut, dan sekarang sedikit tentang "mode manual". Dalam mode ini, operator memilih shanket yang diinginkan, menyiapkannya untuk gerakan (menghubungkan motor ke inverter), menetapkan tanda (posisi target) untuk shanket, dan segera setelah menetapkan kecepatan lebih besar dari nol, shanket mulai bergerak. Untuk mengatur kecepatan, adjuster fisik khusus digunakan, dalam bentuk "potensiometer dengan tombol", tetapi ada juga "adjuster layar" kecepatan. Semakin "berbalik", semakin lebih keras berjalan lebih cepat. Kecepatan maksimum dibatasi hingga 1,5 m / s. Kenop Kecepatan - satu untuk semua. Yaitu Dalam mode manual, semua shanket yang terhubung dengan operator bergerak pada kecepatan yang sama. Meskipun mereka dapat bergerak ke arah yang berbeda (tergantung di mana operator mengarahkan mereka). Tentu saja, sulit bagi seseorang untuk melacak lebih dari dua atau tiga shtanket secara bersamaan, jadi biasanya mereka tidak banyak bergerak dalam mode manual. Dari dua stasiun, operator dapat secara simultan mengelola masing-masing shtanket mereka. Selain itu, setiap konsol (operator) memiliki pengontrol kecepatannya sendiri.
Dari sudut pandang implementasi, mode manual tidak mengandung logika khusus. Perintah untuk menghubungkan mesin berasal dari antarmuka grafis, diubah menjadi pesan ke aktor yang sesuai, yang bekerja di dalamnya. Melewati status "mati" -> "menghubungkan" -> "terhubung". Sama dengan mengatur posisi untuk pergerakan stunket dan mengatur kecepatan. Semua peristiwa ini sampai pada aktor dalam bentuk pesan yang dia bereaksi. Kecuali dapat dicatat bahwa antarmuka grafis dan proses kontrol itu sendiri adalah proses yang berbeda dan di antara mereka ada interaksi "proses" melalui "sensor" menggunakan libuniset2 .
Mode eksekusi skrip (lagi, aktor-aktor ini?)
Bahkan, mode kontrol manual hanya digunakan untuk nongkrong saat latihan atau dalam kasus sederhana. Mode utama di mana kontrol sedang berlangsung adalah "mode eksekusi skrip" atau, singkatnya, "mode skrip". Dalam mode ini, setiap shtank bergerak ke titiknya dengan parameter yang ditentukan dalam skrip (kecepatan dan tanda target). Untuk operator, kontrol dalam mode ini terdiri dari dua perintah sederhana:
- bersiap-siap (grup mesin yang tepat terhubung)
- ayo pergi (grup mulai bergerak ke posisi target yang ditetapkan untuk masing-masing).
Seluruh skenario dibagi menjadi apa yang disebut "agenda". Agenda adalah salah satu gerakan kelompok shtanket. Yaitu setiap agenda mencakup sekelompok shtanket, dengan kecepatan target dan merek tempat Anda harus datang. Bahkan, naskah dibagi menjadi babak, babak dibagi menjadi lukisan, lukisan dibagi menjadi beberapa panggilan pengadilan, dan panggilan pengadilan sudah terdiri dari "tujuan" untuk shtankets tertentu. Tetapi dari sudut pandang manajemen, divisi ini tidak penting, karena pada agenda itulah parameter spesifik gerakan diindikasikan pada akhirnya.
Untuk menerapkan rezim ini, sistem aktor muncul kembali sebaik mungkin. “Pemain skrip” dikembangkan yang menciptakan sekelompok aktor khusus dan meluncurkan mereka. Kami telah mengembangkan dua jenis aktor: aktor-aktor, yang dirancang untuk melakukan tugas-tugas untuk shtanket tertentu, dan aktor-koordinator, yang mendistribusikan tugas di antara para pelaku. Apalagi aktor yang tampil diciptakan seperlunya, jika pada saat tim berikutnya tidak bebas. Aktor koordinator bertanggung jawab untuk menciptakan dan memelihara kumpulan aktor yang berkinerja baik. Akibatnya, manajemen terlihat seperti ini:
- pernyataan memuat skrip
- "Balikkan" ke agenda yang diinginkan (biasanya hanya berurutan).
- pada saat yang tepat, tekan tombol "persiapan", di mana perintah (pesan) dikirim ke aktor koordinator untuk setiap formlet yang termasuk dalam agenda saat ini dengan parameter gerakan.
- Aktor-koordinator melihat kumpulan aktor berkinerja bebasnya, mengambil aktor gratis (jika dia tidak membuat aktor baru) dan memberinya tugas (jumlah shankets dan parameter gerakan).
- Setiap aktor-aktor yang telah menerima tugas mulai memenuhi perintah "bersiap-siap". Yaitu itu menghubungkan mesin dan memasuki mode siaga dari perintah "pergi".
- ketika saatnya tiba, operator memberi perintah "ayo pergi"
- tim "pergi" mendatangi koordinator. Dia mengirimkannya ke semua pemain yang saat ini aktif dan mereka mulai "eksekusi."
Perlu dicatat bahwa dalam agenda ada parameter tambahan. Misalnya, mulai gerakan dengan penundaan N detik atau mulai gerakan hanya setelah perintah operator khusus yang terpisah. Oleh karena itu, daftar negara untuk masing-masing aktor yang tampil cukup besar: "siap untuk mengeksekusi perintah berikutnya", "siap untuk bergerak", "gerakan tertunda", "menunggu perintah operator", "gerakan", "eksekusi selesai", "kerusakan" .
Setelah shanket berhasil (atau tidak) mencapai tanda yang ditentukan, aktor-pemain memberi tahu koordinator dari tugas yang diselesaikan. Koordinator memberikan perintah untuk mematikan mesin ini (jika tidak lagi berpartisipasi dalam agenda saat ini) atau mengeluarkan parameter gerakan baru. Pada gilirannya, aktor-pemain menerima perintah untuk mematikan mesin, mematikannya dan masuk ke keadaan menunggu perintah baru, atau mulai menjalankan perintah baru.
Karena fakta bahwa sobjectizer memiliki API yang dipikirkan dengan baik dan nyaman untuk bekerja dengan negara, kode implementasi cukup singkat. Misalnya, penundaan gerakan dijelaskan dalam satu baris:
st_delay.time_limit( std::chrono::milliseconds{target->delay()}, st_moving ); st_delay.activate(); ...
Fungsi time_limit menetapkan batas waktu berapa banyak yang bisa dihabiskan dalam keadaan tertentu dan keadaan apa yang harus dilewati setelah waktu yang ditentukan (st_moving).
Aktor Perlindungan
Tentu saja, selama operasi, kerusakan dapat terjadi. Sistem diperlukan untuk menangani situasi ini. Di sini juga ada tempat untuk penggunaan aktor. Pertimbangkan beberapa perlindungan ini:
- lebih dari perlindungan saat ini
- perlindungan kegagalan pengukuran
- perlindungan terhadap gerakan dalam arah yang berlawanan (dan ini bisa terjadi, jika ada yang salah dengan sensor atau meteran)
- perlindungan terhadap gerakan tanpa perintah
- kontrol pelaksanaan tim (kontrol bahwa shtanket mulai bergerak)
Anda dapat melihat bahwa semua perlindungan ini independen (mandiri) dari sudut pandang implementasi, dan harus bekerja "secara paralel". Yaitu kondisi apa pun bisa bekerja. Pada saat yang sama, logika memeriksa kondisi pemicu untuk masing-masing perlindungan memiliki sendiri, kadang-kadang diperlukan penundaan (penghitung waktu) untuk pemicu, kadang-kadang diperlukan pemrosesan awal dari beberapa pengukuran sebelumnya, dll. Oleh karena itu, penerapan setiap jenis perlindungan sebagai aktor kecil yang terpisah ternyata sangat nyaman. Semua aktor ini diluncurkan sebagai tambahan (bekerja sama) dengan aktor utama yang mengimplementasikan logika kontrol. Pendekatan ini memudahkan untuk menambahkan tipe pertahanan tambahan hanya dengan menambahkan aktor lain ke grup. Pada saat yang sama, implementasi aktor seperti itu tetap cukup mudah dan dapat dimengerti, karena Ini hanya mengimplementasikan satu fungsi.
Aktor perlindungan juga memiliki beberapa negara. Pada dasarnya mereka menghidupkan (masuk ke "on" state) hanya ketika mesin terhubung atau betis bergerak. Ketika kondisi untuk perlindungan dipicu, mereka menerbitkan pemberitahuan tentang perlindungan yang dipicu (dengan kode keamanan dan beberapa detail untuk penebangan), aktor utama sudah menanggapi pemberitahuan ini, yang, jika perlu, mematikan mesin dan beralih ke mode perlindungan.
Sebagai kesimpulan ..
... tentu saja artikel ini bukan semacam "penemuan". Pendekatan aktor telah lama berhasil digunakan dalam banyak sistem. Tetapi bagi saya itu adalah pengalaman pertama secara sadar menggunakan pendekatan aktor untuk membangun algoritma sistem kontrol dalam proyek yang relatif kecil. Dan pengalaman itu cukup berhasil. Saya harap saya dapat menunjukkan bahwa para aktor sangat baik ditumpangkan pada algoritma kontrol, mereka menemukan tempat secara harfiah di mana-mana.
Dari pengalaman proyek sebelumnya, jelas bahwa satu atau lain cara kami menerapkan "sesuatu seperti itu" (status, pesan, kontrol aliran, dll.), Tetapi ini bukan pendekatan terpadu. Menggunakan sobjectizer, kami mendapatkan alat pengembangan yang ringkas dan ringan yang menghasilkan banyak masalah. Tidak lagi diperlukan (eksplisit) untuk menggunakan alat sinkronisasi (mutex, dll.), Tidak ada kerja eksplisit dengan stream, tidak ada realisasi mesin negara. Semua ini ada dalam kerangka kerja, secara logis saling berhubungan dan disajikan sebagai API yang nyaman, apalagi, tanpa kehilangan kendali atas detail. Jadi pengalaman itu menarik. Bagi mereka yang masih ragu, saya sarankan memperhatikan pendekatan aktor dan kerangka sobjectizer pada khususnya. Dia meninggalkan emosi positif.
Dan pendekatan aktor benar-benar berhasil! Terutama di teater.