Concurrency, Parallelism, Asynchrony, Non-blocking และแนวคิดต่าง ๆ

เริ่มจากการจัดระเบียบคำศัพท์แบบง่าย ๆ แล้วขยายไปครอบคลุมตั้งแต่กราฟิกไปจนถึงเซมิคอนดักเตอร์

1. คำศัพท์
   • Concurrency / Parallelism
   • Asynchrony / Non-blocking
   • Preemptive / Non-preemptive
2. ระบบปฏิบัติการและโปรเซสเซอร์
   • ระบบปฏิบัติการ
   • โปรเซสเซอร์
3. Coroutine และ Fiber
   • Fiber
   • Coroutine
4. Generator, Async/Await, Continuation
   • Generator
   • Async / Await
   • Continuation
5. Promise และ Future
6. I/O Multiplexing
   • Multiplexing
   • Socket
   • โมเดล I/O ต่าง ๆ
7. Ring Buffer, โมเดล I/O สมัยใหม่, LMAX Disruptor
   • Ring Buffer
   • โมเดล I/O สมัยใหม่
   • LMAX Disruptor
8. Synchronization Primitive
   • ความจำเป็น
   • Thread safety
   • Spinlock
   • Mutex
   • Semaphore
   • STM
   • GIL
9. แนวทางของภาษา scripting อื่น ๆ และแพตเทิร์น Reactor/Proactor
   • Ractor (Ruby)
   • Node.js (แพตเทิร์น Reactor)
   • แพตเทิร์น Proactor
10. CSP และ Actor
    • CSP
    • Actor
11. Green Thread, Goroutine และเทคโนโลยี async runtime สมัยใหม่
    • Green Thread
    • CSP runtime สมัยใหม่
    • Actor runtime สมัยใหม่
12. การประมวลผลแบบขนาน
    • SIMD และ Pipelining
    • OpenMP & MPI
    • เทคนิคการประมวลผลแบบขนานสมัยใหม่
    • Lambda Architecture
13. GPU
    • Pipeline และ Shader
    • มอนิเตอร์
    • Buffering
    • Vertical Synchronization
    • Frame pacing และ Beam racing
    • Compositor
    • Graphics API / Library
14. ชิปอื่น ๆ
    • ภาพรวม
    • DSP
    • FPGA
    • TPU
15. อ้างอิง

[roxie]

แบบซิงโครนัสและอะซิงโครนัสคือใครเป็นผู้ตรวจสอบว่างานเสร็จแล้ว
แบบบล็อกกิงและนอนบล็อกกิงคือมีสิทธิ์ควบคุมหรือไม่

เห็นประโยคนี้ถูกพูดซ้ำเหมือนกันเป๊ะในบล็อกนับไม่ถ้วน เลยสงสัยว่าต้นทางดั้งเดิมมาจากไหน

บล็อกส่วนใหญ่มัวแต่อ้างอิงกันไปมากันมา จนเดาต้นฉบับไม่ออกเลย ที่พอหาเจอมีแค่เอกสาร AIO ของ IBM เอกสาร AIO แต่ก็รู้สึกว่านี่อาจพูดจำกัดอยู่แค่ kernel I/O หรือเปล่า อีกทั้งก็ได้ยินมาว่าเกณฑ์การแบ่งแบบนั้นเองก็ยังมีข้อถกเถียงอยู่ด้วย

ถือเป็นเกณฑ์ตัดสินที่น่าเชื่อถือได้หรือไม่?

[alstjr7375]

ก่อนอื่น หากอิงจากฝั่งวงจร คิดว่าน่าจะอธิบาย synchronous/asynchronous ได้ครับ
วงจร synchronous ใช้นาฬิกาเพื่อกำหนดจังหวะเวลา ส่วน asynchronous จะเป็นวิธีที่ถูกทริกเกอร์ด้วยอีเวนต์หรืออินพุตอื่น ๆ
กล่าวคือ การนิยามว่า asynchronous API เป็นวิธีที่ถูกทริกเกอร์ด้วย callback เป็นต้น ก็คงไม่ถือว่าฝืนความหมายมากนัก
https://developer.mozilla.org/en-US/docs/…

สำหรับ blocking/non-blocking API คำจำกัดความที่เหมาะสมคือ ต้องรอให้งานเสร็จก่อนหรือไม่
อย่างไรก็ตาม ดูเหมือนว่าจะมีแนวโน้มอธิบายกันในลักษณะนั้นมาก เพราะเพื่อที่จะไม่ต้องรอ จะต้องมี implementation ที่ทำให้ฟังก์ชันที่ถูกเรียกยังคงถือครองการควบคุมอยู่
https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/

เดิมทีผมตั้งใจจะข้ามแบบสั้น ๆ เลยละไว้ แต่จะลองเพิ่มเนื้อหาส่วนนี้เข้าไปเพิ่มเติมครับ

[roxie]

ผมเห็นด้วยกับสิ่งที่คุณเขียนมาทั้งหมดครับ แต่ผมก็ยังไม่แน่ใจนักว่าควรวาดแกนเกณฑ์ทั้งสองนี้ลงบนระนาบแบบสี่ควอดแรนต์หรือไม่ วาดได้จริงหรือไม่ และสามารถแยกความแตกต่างกันได้อย่างเหมาะสมหรือไม่ สำหรับผม Blocking กับ Sync ให้ความรู้สึกว่าในเชิงแนวคิดมีบริบทร่วมกันอยู่ 90% ส่วน Non-Blocking กับ Async ก็เช่นเดียวกันครับ

[alstjr7375]

แม้ว่า Blocking-Sync และ Non-Blocking-Async มักจะถูกใช้ควบคู่กัน แต่ก็มีกรณีที่จำเป็นต้องแยกแยะความแตกต่างกัน

• Blocking-Async: I/O multiplexing อย่าง select
• Non-Blocking-Sync: การ polling ข้อมูล

เพราะอย่างนั้น ผมจึงคิดว่าการแยกใช้ให้ชัดเจนน่าจะถูกต้องมากกว่า

[roxie]

ดูเหมือนว่าคุณยังไม่ค่อยมีภาพร่วมกับตัวอย่างที่ยกมา เพราะยังไม่ค่อยเข้าใจตัวอย่างเหล่านั้นมากนัก

https://incredible-larva.tistory.com/entry/IO-Multiplexing-Topabogi-1bu บทความนี้อธิบายไว้ดังนี้:

สุดท้ายแล้ว user process ที่เรียก select จะเป็นฝ่ายดูค่าที่ return กลับมา แล้วตัดสินใจว่ามีงานถัดไปต้องทำหรือไม่ แม้อาจมองว่าเป็น Asynchronous ได้ เพราะมีการจัดการ I/O request หลายรายการที่เข้ามาอย่างคาดเดาไม่ได้พร้อมกัน แต่ท้ายที่สุดการทำงานของ I/O แต่ละรายการจริง ๆ ก็ยังแสดงพฤติกรรมแบบ Synchronous อยู่

ผมเลยอยากทราบว่าคุณมีความเห็นอย่างไรกับประเด็นนี้ จริง ๆ สำหรับผม พอมาถึงจุดนี้ก็เริ่มรู้สึกว่าการแบ่งแบบ 2x2 นี้ไม่ได้มีความหมายมากนักแล้ว เพราะดูเหมือนว่าแต่ละโดเมนและแต่ละมุมมองจะตีความกันไปคนละแบบ

[alstjr7375]

ต่อมา เมื่อรอการตอบสนองจาก kernel ก็จะมีสัญญาณ callback จาก kernel ว่าผลลัพธ์พร้อมแล้ว และ user process จะแสดงลักษณะการคัดลอกข้อมูลมายัง buffer ของตัวเอง

ส่วนนี้เป็นรูปแบบการทริกเกอร์ด้วย callback ตามที่เห็นพ้องกันไว้ข้างต้น ดังนั้นหากจำเป็นต้องแยก/นิยามให้ชัด ก็ดูเหมือนว่าจะเรียกว่า Blocking-Async จะเหมาะสมกว่า
ผมคิดว่าในบางกรณีอาจดูคลุมเครือได้ขึ้นอยู่กับมุมมอง

อย่างไรก็ตาม polling เป็นตัวอย่างที่ชัดเจนครับ
https://en.wikipedia.org/wiki/Polling_(computer_science)

ในกรณีของ polling เนื่องจากมีการตรวจสอบซ้ำ ๆ ว่าข้อมูลพร้อมหรือยัง จึงเป็นตัวอย่างที่เหมาะสมของ Sync-Blocking ครับ

[wonkwh]

ว้าว ขอบคุณสำหรับข้อมูลดี ๆ ครับ

[kayws426]

อ่านได้เพลินมากครับ!

[bus710]

เลื่อนไปเท่าไหร่ก็เหมือนไม่มีที่สิ้นสุดเลย
ดูเหมือนว่าหนังสือชื่อ "7 รูปแบบความพร้อมกัน" ที่ว่าด้วยหัวข้อคล้ายกันก็น่าอ่านสักครั้งเหมือนกันครับ

[alstjr7375]

ดูจากการเปรียบเทียบสารบัญแล้วคล้ายกันนะ
ดูเหมือนจะเป็นหนังสือที่ดี