OLSRT: รันไทม์ Concurrency ในภาษา C11 พร้อมระบบ Actor และ Event Loop
เปิดตัว OLSRT รันไทม์ C11 แบบโอเพนซอร์สใต้ไลเซนส์ Apache-2.0 ที่รวบรวมระบบ actor, channel และ event loop ไว้ในชุดเดียวโดยไม่มีไลบรารีภายนอก

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- OLSRT คือรันไทม์ C11 แบบโอเพนซอร์สใต้ไลเซนส์ Apache-2.0 ที่รวมระบบ actor, channel และ event loop ไว้ในที่เดียว
- พัฒนาด้วยภาษา C11 ล้วน ไม่มี C++, ไม่มี garbage collector และไม่มีไลบรารีภายนอกนอกเหนือจาก pthreads และ standard library
- อัปเดตล่าสุดแก้ไข 11 บั๊กสำคัญพร้อมเพิ่มชุดทดสอบ 22 ข้อที่ผ่านการรันด้วย ASan, UBSan และ TSan สำเร็จ
- มาพร้อมเดโม 7 โปรแกรมในโฟลเดอร์ demos/ และสคริปต์ verify.py สำหรับตรวจสอบความถูกต้องอัตโนมัติ
เมื่อสี่ปีที่แล้ว การเขียนโค้ด Concurrent ด้วยภาษา C บนระบบปฏิบัติการ Linux มักบังคับให้นักพัฒนาต้องเขียนโครงสร้างพื้นฐานเดิมซ้ำๆ ไม่ว่าจะเป็น epoll wrapper, thread pool, lock-free queue, promise type ไปจนถึงระบบปิดการทำงานที่สะอาดโดยไม่ให้เกิดหน่วยความจำรั่วไหล แม้โครงการบางแห่งจะเลือกใช้ไลบรารีอย่าง libuv ได้สำเร็จ แต่โปรเจกต์ส่วนใหญ่ก็ยังคงต้องเสียเวลาสร้างระบบเหล่านี้ขึ้นมาใหม่เองอยู่ดี
เพื่อแก้ปัญหานี้ ทางทีมพัฒนาจึงได้สร้าง OLSRT ขึ้นมา ซึ่งเป็น C11 runtime ภายใต้ไลเซนส์ Apache-2.0 ที่รวบรวมองค์ประกอบพื้นฐานเหล่านี้ไว้ในที่เดียว พร้อมโมเดลการเป็นเจ้าของข้อมูล (ownership model) ที่สอดคล้องกันและมี event loop เดี่ยวทำหน้าที่เชื่อมโยงทุกอย่างเข้าด้วยกันอย่างลงตัว
จุดเด่นสำคัญคือโครงสร้างทั้งหมดเขียนด้วยภาษา C11 แท้ๆ ปราศจากการใช้งาน C++, ไม่มีระบบ garbage collector และไม่มีการพึ่งพาไลบรารีภายนอกใดๆ เพิ่มเติมนอกเหนือจาก pthreads และ standard library พื้นฐานเท่านั้น

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
สำหรับการปล่อยอัปเดตเวอร์ชันก่อนหน้านี้เคยถูกปล่อยออกมาโดยไม่มีชุดทดสอบอย่างเป็นทางการ จนกระทั่งต่อมาทีมงานพบข้อผิดพลาดจริงถึง 11 จุด ทางทีมจึงใช้เวลาหนึ่งสัปดาห์เต็มในการเขียนชุดทดสอบ regression test ก่อนจะเริ่มลงมือแก้ไขทีละจุดพร้อมเปิดใช้งาน ASan, UBSan และ TSan ในทุกๆ commit ที่ส่งโค้ดเข้าไป
รายการข้อผิดพลาดที่พบและแก้ไขถือว่ามีประโยชน์อย่างยิ่งในการเรียนรู้ เช่น บั๊กประเภท heap-use-after-free ที่ตรวจพบได้เฉพาะผ่าน ASan และบั๊กด้าน memory-ordering ใน lock-free ring buffer ปัจจุบันโปรเจกต์นี้มีข้อกำหนดการตรวจสอบ (assertions) ทั้งหมด 22 ข้อกระจายอยู่ใน 6 ชุดทดสอบ ซึ่งทั้งหมดผ่านการรันอย่างไร้ที่ติภายใต้แฟล็ก -fsanitize=address,undefined และ -fsanitize=thread แม้ตัวเลขนี้จะไม่ใช่ชุดทดสอบขนาดใหญ่โตมโหฬาร แต่ก็เป็นเส้นแบ่งสำคัญระหว่างรันไทม์ที่คุณกล้าใช้งานกับโปรเจกต์จริงและรันไทม์ที่ไม่น่าไว้วางใจ
การพัฒนา Concurrency Runtime ตั้งแต่เริ่มต้นด้วยภาษา C11 ล้วนถือเป็นความท้าทายระดับสูง เนื่องจากนักพัฒนาต้องบริหารจัดการหน่วยความจำและลำดับการประมวลผล (Memory Ordering) ด้วยตนเองโดยไม่มีตัวช่วยอย่าง Garbage Collector การที่ OLSRT เลือกใช้เครื่องมือตรวจสอบความปลอดภัยอย่าง AddressSanitizer (ASan), UndefinedBehaviorSanitizer (UBSan) และ ThreadSanitizer (TSan) ตั้งแต่เนิ่นๆ จึงช่วยป้องกันปัญหาบั๊กด้านหน่วยความจำเรื้อรังที่มักตรวจพบได้ยากในระบบมัลติทิตส์
นอกจากนี้ ในโฟลเดอร์ demos/ ยังมีโปรแกรมขนาดเล็กจำนวน 7 โปรแกรมที่ถูกออกแบบมาให้ทำงานได้ด้วยตัวเองแบบ self-contained โปรแกรมเหล่านี้ไม่ใช่การทดสอบเพื่อวัดประสิทธิภาพ (Benchmarks) แต่เป็นเครื่องมือตรวจสอบการทำงานจริงว่าตัวระบบสามารถใช้งานได้จริงหรือไม่ ตัวอย่างเช่น Demo 02 สามารถส่งข้อความจำนวน 1,000,000 ข้อความผ่าน channel ขนาด 1024-slot บนฮาร์ดแวร์ AMD E2-1800 (แบบ dual-core ความเร็ว 1.7 GHz) ได้ด้วยความเร็วประมาณ 386,000 ข้อความต่อวินาที ส่วน Demo 04 แสดงให้เห็นความคลาดเคลื่อนของเวลา (timer drift) ที่ต่ำกว่าสองไมโครวินาทีจากการทำงานเป็นรอบหกครั้ง แม้ตัวเลขเหล่านี้อาจดูไม่สูงมากนักเมื่อเทียบกับฮาร์ดแวร์ยุคปัจจุบันเนื่องจากเครื่องทดสอบถูกผลิตตั้งแต่ปี 2012 แต่ก็ยืนยันได้ว่าโครงสร้างพื้นฐานภายในกำลังทำงานตามที่ระบุไว้จริง
"The trickiest bug we fixed was a memory-ordering issue in a lock-free ring buffer that only shows up on ARM. Has anyone else written a similar primitive and can share how they tested it?"
ทีมพัฒนา OLSRT
ผู้ที่สนใจสามารถเข้าไปดูแผนงานพัฒนา (Roadmap) ฉบับสมบูรณ์ได้จากไฟล์ ROADMAP.md ภายในrepository โดยคำสั่งสำหรับการทดสอบและใช้งานเบื้องต้นมีดังนี้:
- git clone https://github.com/OverLab-Group/OLSRT.git
- cd OLSRT
- make linux
- python3 verify.py
สคริปต์ verify.py จะใช้เวลาทำงานประมาณสองนาทีบนแล็ปท็อปยุคใหม่ โดยจะรายงานผลว่าผ่านการตรวจสอบทั้งสี่รายการหรือไม่ หรือระบุไฟล์ที่เกิดข้อผิดพลาดให้ทราบอย่างชัดเจน ทั้งนี้ ทางผู้พัฒนายังคงเปิดรับรายงานข้อผิดพลาดเพิ่มเติมจากชุมชนนักพัฒนาอย่างต่อเนื่อง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น