IPC – Đằng sau sự thành công của Chromium

Dạo gần đây mình đang quan tâm về Electron JS, trong quá trình tìm hiểu về kiến trúc của Electron thì mình có gặp một định nghĩa đó là IPC. Mình mới bắt đầu Google và nhận ra khá nhiều thứ hay ho. Chúng ta cùng tìm hiểu thêm nhé!

Một process (tiến trình) trong hệ điều hành có thể được tiến hành độc lập hoặc giao tiếp với nhau.

Process độc lập là khi process không ảnh hưởng hoặc bị ảnh hưởng bởi các process khác trong hệ thống, và không chia sẻ data với bất kì process nào. Process giao tiếp khi process đó có thể ảnh hưởng hoặc bị ảnh hưởng bởi các process khác trong hệ thống, và sự chia sẻ data có diễn ra.

Vì sao các process phải giao tiếp với nhau?

Việc cho phép truyền data giữa các process là do những lý do sau:

Giúp chia sẻ thông tin giữa các users có trong hệ điều hành.
Giúp speech up các tác vụ trong máy tính.
Giúp xây dựng module.
Giúp thuận tiện trong chạy nhiều tác vụ cùng một lúc.

IPC là viết tắt của từ gì?

Inter Process Communication (hay còn gọi là IPC) – giao tiếp giữa các process – là một phương thức không thể thiếu trong việc giúp các process trao đổi thông tin với nhau.

Hai models chính của IPC là shared memory (chia sẻ bộ nhớ) – với nhiệm vụ hình thành khu vực lưu trữ bộ nhớ chung – và message passing (truyền tin) – với nhiệm vụ truyền tải tin nhắn liên tục giữa các process.

Đến đây mình mới ngờ ngợ ra là mình dung cái thứ 2 suốt trong Lập trình Web 😀

Cả hai model trên đều phổ biến trong các hệ điều hành ngoài ra nó còn phổ biến ở những vấn đề khác nữa.

Model message passing hữu ích cho việc trao đổi số lượng nhỏ các data và dễ thực hiện hơn trong hệ cơ sở dữ liệu phân tán – hệ thống phân tán (distributed system).
Ngược lại, shared memory có thể nhanh hơn message passing vì các hệ thống truyền thông điệp thường thực hiện thông qua system call (mà chúng tốn nhiều thời gian hơn và phải có sự can thiệp của kernel – nhân hệ điều hành).

Trong hệ thống shared memory, các system call chỉ thực hiện khi cần thiết lập các vùng bộ nhớ chung. Nghĩa là các processor CPU có thể tự do đọc ghi trong phần bộ nhớ này.

Các nghiên cứu gần đây đã chỉ ra rằng message passing tốt hơn shared memory khi sử dụng trong các hệ thống core processing vì các sự cố đồng bộ cache mà shared memory dễ gặp phải khi các data chạy qua caches.

Shared-Memory Systems

IPC sử dụng model shared memory sẽ cần những process tham gia mở một vùng nhớ chung. Vùng nhớ chung này được tạo thành từ nhiều vùng nhớ riêng của mỗi process.

Các process khác muốn tiếp cận vùng nhớ đó sẽ phải lưu địa chỉ của vùng nhớ chung ấy vào vùng nhớ riêng của mình . Mà thông thường, hệ điều hành sẽ chặn không cho các process xâm nhập bộ nhớ của nhau.

Để sử dụng model shared memory, các process cần cho phép việc truy cập bộ nhớ của nhau để có thể sử dụng và viết data trên vùng chia sẻ chung. Các tiến trình sẽ quyết định kiểu data nào được chia sẻ và vùng chia sẻ chung ở đâu. Tất nhiên chúng phải bảo đảm các vùng chia sẻ chung không bị ghi đè lên nhau.

Hơi mông lung nhỉ. Làm tí ví dụ cho dễ hiểu nhé:

Người yêu bạn cần bạn nấu cho 10 cốc trà sữa.
Coi trà sữa là data. Bạn là process nấu. Người yêu bạn là process ăn 😀
Việc bạn và người yêu cùng thực hiện nhiệm vụ, đứa thì nấu, đứa thì ăn trong cùng thời điểm để đảm bảo không ai chờ đợi ai à đây chính là cơ chế của IPC.
Mọi chuyện có vẻ vẫn ổn đúng không nhỉ. Cho đến khi bạn có thêm các EM GÁI MƯA. Vô phúc là các em ý cũng thích uống trà sữa do mình nấu.
Giờ thì chỉ có 1 process nấu, còn lại đang có rất nhiều tàu há mồm (process ăn) đang đợi bạn.
Người yêu thì bảo nấu vị Socola, em gái mưa bảo nấu vị Matcha, em khác bảo nấu vị Bạc Hà, mà trong khi đó có mỗi 1 nồi. Kiểu gì cũng nhầm cho mà xem.

Quay trở lại vấn đề trong hệ thống shared memory, nếu nhiều processor cùng truy cập một vùng nhớ (memory) sẽ gây ra sai sót trong quá trình tính toán.

Nói một cách “toán” hơn, nếu ta khai báo X=0. Cùng lúc có một process A gán X=X+1 và process B gán X=X+2, vậy X lúc này sẽ bằng mấy?

Câu trả lời nếu process nào chạy xong sau, X sẽ có giá trị đó; và đương nhiên chúng ta không thể biết được process nào kết thúc sau.

Hướng giải quyết của vấn đề này là đồng bộ hóa (synchronising) shared data. Nghĩa là nếu processor đầu, sau, cùng lúc tăng giá trị lần lượt lên 1 và 2; thì giá trị cuối cùng luôn luôn là 3 (kệ thằng nào thay đổi giá trị sau cùng kết quả vẫn là 3 sau khi đồng bộ hóa).

Message-Passing Systems

Bên cạnh việc dùng shared memory, một cách khác để liên kết các process lại với nhau là sử dụng message passing.

Message passing cung cấp một cơ chế cho phép các tiến trình liên lạc và đồng bộ mà không cần chia sẻ vùng nhớ (address space) của nhau. Điều này đặc biệt hữu ích trong những hệ cơ sở dữ liệu phân tán (distributed database), nơi mà các process nằm trên các máy tính khác nhau kết nối qua hệ thống mạng. Cụ thể là chương trình chat qua Internet như messenger được thiết kế để người dùng kết nối với nhau thông qua việc trao đổi các tin nhắn.

Khi sử dụng message-passing cần ít nhất 2 thành phần: Gửi tin và Nhận tin. Nói đơn giản thì người nói phải có người nghe.

Process gửi tin có thể cố định hoặc biến đổi về kích thước. Ví dụ, nếu process P và Q muốn trao đổi, các tin cần phải được gửi và nhận giữa hai đầu: một liên kết truyền tin phải tồn tại giữa hai process.

Message-Passing Systems có 2 cách thức: kết nối trức tiếp vào kết nối gián tiếp.

Kết nối trực tiếp

Đối với kết nối trực tiếp: mỗi process muốn truyền tin cần phải đặt tên cho tin nhắn hoặc tên người gửi:

Symmetry: cần cả tên người gửi và tên tin nhắn để process đó thực hiện thao tác gửi
Asymmertry: chỉ cần tên tin nhắn là process đó có thể gửi cho bất kì process nào khác

Kết nối gián tiếp

Đối với kết nối gián tiếp: các tin được nhận thông qua các hộp thư hoặc các cổng.

Nơi tin nhắn được gửi vào hoặc được lấy ra. Mỗi một hộp thư sẽ được xác định bởi 1 ID duy nhất. Các process có thể liên lạc với nhau thông qua nhiều hộp thư, nhưng chỉ khi các hộp thư đó được thiết lập như hộp thư chung giữa hai process.

Kết nối được đồng bộ hoặc không được đồng bộ – blocking và nonblocking.

Dù là dùng Message Passing hay Shared-memory system, vẫn sẽ có trường hợp process A “đợi” process B có thông tin rồi mới thực hiện. Nếu nhiều process cùng “đợi”, sẽ dẫn đến timeout rất lâu, bạn sẽ không muốn khi gửi gói tin/ gửi request và phải đợi rất lâu để có thể nhận data trả về, vậy có cách nào khắc phục tình trạng này? Đó không phải là công việc mà bạn phải lo lắng, bởi hệ điều hành đã thực hiện việc này cho chúng ta, câu trả lời là Process Scheduling.

Hệ điều hành thời nay có thể chạy rất rất nhiều process cùng lúc nhằm tối đa hóa quá trình sử dụng CPU. Vậy khi có quá nhiều các process giao tiếp và xử lý dữ liệu thì hệ điều hành sẽ duy trì các hàng đợi quan trọng sau đây:

Job queue: Hàng đợi này sẽ giữ tất cả các process trong hệ thống.
Ready queue: Hàng đợi này giữ một tập hợp tất cả các quy trình nằm trong bộ nhớ chính, sẵn sàng và chờ thực thi. Một process mới sẽ được đặt trong hàng đợi này.
Device queues: Các thiết bị inoutput sẽ nằm ở queue này.

Hệ điều hành sẽ implement các thuật toán Queue khác nhau như: FIFO, Round Robin, Priority, v.v. Nhiệm vụ chính của Process Scheduling là chọn các công việc sẽ được đưa vào các queue bên trên đã trình bày và quyết định process nào sẽ chạy. Có 3 loại:

Long-Term Scheduler
Short Term Scheduler
Medium-Term Scheduler

Các bạn có thể đọc thêm ở đây: https://www.tutorialspoint.com/operating_system/os_process_scheduling.htm Mỗi loại sẽ có độ ưu tiên xử lý riêng.

Ví dụ thực tế của IPC – trình duyệt Chrome

Như bạn đã biết, không như những trình duyệt khác (ví dụ Firefox phiên bản cũ, phiên bản mới giờ thì ngon rồi), thường có tình trạng đứng 1 tab là đứng hết cả trình duyệt. Nhưng trình duyệt Chrome thì không như vậy.

Đó là nhờ cơ chế multiprocess, mỗi tab của Chrome là một process độc lập với nhau, và chúng luôn chạy đồng thời với nhau.

Kiến trúc multiprocess của Chrome hoạt động trên cơ chế nhận biết 3 kiểu của process:

Brownser process: kiểm soát user interface, disk và network. Chỉ có duy nhất 1 process loại này.

Renderer process: bao gồm cách thức render/ hiển thị một trang web. Mỗi lần bạn bật 1 tab mới, Chrome sẽ tự động tạo 1 process loại này cho bạn. Renderer process chạy trên các sandbox, nghĩa là chúng không cho các process trên trình duyệt có khả năng tiếp cận ổ cứng, hệ thống mạng của người dùng, nhằm tăng độ bảo mật.

Plug-in process: hay còn gọi là extension trên trình duyệt, đây là loại process cần được giao tiếp với hai loại process còn lại. (Ví dụ: Flash)

Vừa rồi thì mình đã trình bày về IPC, các bạn chắc cũng hình dung ra được phần nào rồi chứ. Sau khi viết xong bài viết này mình nhận ra rằng làm ra hệ điều hành thật sự khó đến nhừng nào. Nghĩ vậy mình lại thấy áy náy khi mình đang dùng win lậu @@ Hy vọng rằng bài viết này sẽ áp dụng được cho bạn trong công việc và trong cuộc sống.

Xin chào và hẹn gặp lại…

Tham khảo: https://stream-hub.com/ipc-la-gi/#Vi_sao_cac_process_phai_giao_tiep_voi_nhau