Thông thường, Inter Process Communication sẽ được hiện thực hóa, code trên những mạng lưới hệ thống máy tính song song ( parallel computer ), với những máy ảo nhỏ ( Virtual Private Server – VPS ), việc lập trình IPC là không thiết yếu. Stream Hub sẽ không nói về cách hiện thực IPC trong code mà nêu ra một số ít yếu tố tương quan đến IPC .
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 (bạn có thể tìm hiểu process là gì) là do những lý do sau:
- Giúp chia sẻ thông tin giữa các users.
- Giúp speech up các tác vụ trong máy tính.
- Giúp xây dựng modun.
- 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.
Bạn đang đọc: IPC là gì và cách định thời multi process
Hai models chính của IPC là shared memory ( san sẻ bộ nhớ ) – với trách nhiệm hình thành khu vực tàng trữ bộ nhớ chung – và message passing ( truyền tin ) – với trách nhiệm truyền tải tin nhắn liên tục giữa những process .
Cả hai Model trên đều phổ cập trong những hệ điều hành quản lý. Model message passing hữu dụng cho việc trao đổi số lượng nhỏ những data và dễ thực thi hơn trong hệ cơ sở tài liệu phân tán – mạng lưới hệ thống phân tán ( distributed system ). trái lại, shared memory hoàn toàn có thể nhanh hơn message passing vì những mạng lưới hệ thống truyền thông điệp thường triển khai trải qua system call ( mà chúng tốn nhiều thời hạn hơn và phải có sự can thiệp của kernel – nhân hệ quản lý và điều hành ) .
Trong mạng lưới hệ thống shared memory, những system call chỉ thực thi khi cần thiết lập những vùng bộ nhớ chung. Nghĩa là những processor CPU hoàn toàn có thể tự do đọc ghi trong phần bộ nhớ này .
Các điều tra và nghiên cứu gần đây đã chỉ ra rằng message passing tốt hơn shared memory khi sử dụng trong những mạng lưới hệ thống core processing vì những sự cố đồng điệu cache mà shared memory dễ gặp phải khi những data chạy qua caches .
Shared-Memory Systems
IPC sử dụng Mã Sản Phẩm 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ì, những hệ quản lý và điều hành sẽ chặn không cho những process xâm nhập bộ nhớ của nhau .
Để sử dụng Model shared memory, những process cần được cho phép việc truy vấn bộ nhớ của nhau để hoàn toàn có thể sử dụng và viết data trên vùng san sẻ chung. Các tiến trình sẽ quyết định hành động kiểu data nào được san sẻ và vùng san sẻ chung ở đâu. Tất nhiên chúng phải bảo vệ những vùng san sẻ chung không bị ghi đè lên nhau .
Một ví dụ đơn thuần về việc ăn ở quán ăn cho Model này. Giả sử, bạn gọi 10 phần ăn, những món ăn được đem lên từ từ. Cho thức ăn là data cần truyền, người ăn là process cần data và đầu bếp là process phân phối data. Việc đầu bếp và người ăn cùng thực thi trách nhiệm của mình trong cùng thời gian để bảo vệ thời hạn ăn không bị ngắt quãng và lâu. chính là chính sách IPC. Và chi tiết cụ thể hơn, họ cùng share một lượng data / thức ăn. Với điều kiện kèm theo, người ăn không được ăn ( write data ) lên phần mà đầu bếp chưa chế biến .
Vấn đề IPC trong hệ thống Shared Memory
Trong ví dụ về quán ăn ở trên, bạn có nhận ra sự không tốt ? Giả sử nếu nhiều thực khách cùng lúc order một món ăn, món ăn đó sẽ thế nào ? Quay trở lại yếu tố trong mạng lưới hệ thống shared memory, nếu nhiều processor cùng truy vấn một vùng nhớ ( memory ) sẽ gây ra sai sót giám sát .
Nói một cách “toán” hơn, nếu ta khai báo x với giá trị ban đầu là 0. Cùng lúc processor 1 tăng biến x lên 1 và processor 2 tăng biến x lên 2, x sẽ có kết quả là? Câu trả lời nếu processor nào chạy xong sau, x sẽ có giá trị đó; và đương nhiên chúng ta không thể biết được processor nào kết thúc sau.
Hướng xử lý của yếu tố này là đồng nhất 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ị ở đầu cuối luôn luôn là 3 ( kệ thằng nào đổi khác giá trị ở đầu cuối tác dụng vẫn là 3 sau khi đồng nhất hóa ) .
Message-Passing Systems
Bên cạnh việc dùng shared memory, một cách khác để link những process lại với nhau là sử dụng message passing .
Message passing cung ứng một chính sách được cho phép những tiến trình liên lạc và đồng nhất mà không cần san sẻ vùng nhớ ( address space ) của nhau. Điều này đặc biệt quan trọng hữu dụng trong những hệ cơ sở tài liệu phân tán ( distributed database ), nơi mà những process nằm trên những máy tính khác nhau liên kết qua mạng lưới hệ thống mạng. Cụ thể là chương trình chat qua Internet như messenger được phong cách thiết kế để người dùng liên kết với nhau trải qua việc trao đổi những tin nhắn .
Cơ sở truyền in phân phối tối thiểu hai nguồn :
Gửi ( tin ) < => nhận ( tin )
Process gửi tin hoàn toàn có thể cố định và thắt chặt hoặc biến hóa về kích cỡ. Ví dụ, nếu process P và Q. muốn trao đổi, những tin cần phải được gửi và nhận giữa hai đầu : một link truyền tin phải sống sót giữa hai process .
Message-Passing Systems có 2 phương pháp : liên kết trức tiếp vào liên kết gián tiếp .
Kết nối trực tiếp
o Đối với liên kết 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
o Đối với liên kết gián tiếp : những tin được nhận trải qua những hộp thư hoặc những cổng .
- Hộp thư:
- 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
o Chặn gửi : process gửi tin bị chặn cho đến khi tin nhắn đã được nhận bởi process còn lại hoặc tới khi tin vào hộp thư .
o Không chặn gửi : process gửi tin xong thì liên tục hoạt động giải trí .
o Chặn nhận : Process nhận tin chặn cho đến khi một tin nhắn có sẵn .
o Không chặn nhận : process nhận tin sẽ nhận một tin hoàn hảo hoặc một giá trị null .
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à bộ định thời.
Định thời CPU (Process Scheduling)
Mục tiêu của IPC nói trên là để những process khác nhau hoàn toàn có thể nhận thông tin của nhau, và nếu bạn muốn quy trình gửi – nhập được diễn ra đúng và đúng mực, đó là việc của bộ định thời .
Mục tiêu của việc đa chương trình là lúc nào cũng có những chương trình ( process khác nhau ) chạy xuyên thấu để tối đa hóa sử dụng CPU. Mục tiêu của việc san sẻ thời hạn là quy đổi CPU giữa những quy trình đó một cách liên tục để người dùng hoàn toàn có thể tương tác với mỗi chương trình trong lúc nó hoạt động giải trí .
Một chương trình chuyển dời giữa những hàng đợi khác nhau trong suốt thời hạn của nó. Hệ điều hành quản lý sẽ phải chọn ra những chương trình từ những hàng chờ vào một lúc nào đó. Việc lựa chọn chương trình được thực thi bởi một scheduler thích hợp .
Thông thường, trong một mạng lưới hệ thống, nhiều chương trình được chọn để xem xét hơn là hoạt động giải trí ngay lập tức. Những chương trình được tàng trữ trong bộ nhớ của thiết bị ( thường thì là ổ đĩa ), đó là nơi tàng trữ để hoạt động giải trí sau này. long-term scheduler hoặc job scheduler sẽ chọn những chương trình từ chỗ này và tải chúng vào bộ nhớ để hoạt động giải trí. Short-term scheduler hoặc CPU scheduler sẽ chọn từ những chương trình đã sẵn dàng để hoạt động giải trí và phân chia CPU cho một trong số chúng
Sự khác nhau cơ bản giữa hai bộ lập trình này nằm ở tần suất hoạt động giải trí. Short-term scheduler phải chọn một chương trình mới cho CPU tiếp tục. Mỗi chương trình hoàn toàn có thể hoạt động giải trí chỉ trong vòng một vài phần nghìn giây trước khi chờ một nhu yếu I / O .
Thông thường, Short-term scheduler hoạt động giải trí tối thiểu mỗi 100 phần nghìn giây. Bởi vì những hoạt động giải trí như vậy, Short-term scheduler phải nhanh. Nếu tốn 10 phần nghìn giây để quyết định hành động hoạt động giải trí một chương trình 100 phần nghìn giây thì 10 / ( 100 + 10 ) = 9 Tỷ Lệ CPU đang được dùng chỉ để lên kế hoạch ( Tỷ Lệ tiêu tốn lãng phí ) .
Một số thuật ngữ khác trong quá trình liên lạc giữa các process
o Zero capacity : bộ đệm không được cho phép bất kể tin nhắn chờ nào, cũng có nghĩa là process gửi tin sẽ bị chặn đến khi bên kia nhận tin .
o Bounded capacity : sẽ có một số lượng giới hạn n những tin nhắn được chờ trong buffer. Có nghĩa là nếu vẫn chưa tới số lượng giới hạn, những tin hoàn toàn có thể liên tục được tạo ra bởi process gửi tin. Nếu đã có n tin nhắn đang chờ được nhận, process này sẽ bị chặn đến khi hàng tin nhắn được trống ( bên kia nhận tin )
o Unbounded capacity : lượng tin nhắn chờ là vô tận, nghĩa là process gửi không khi nào bị chặn .
Trường hợp zero capacity thường được xem là trường hợp giữa hai process không có bộ nhớ đệm, còn hai trường hợp bounded và unbound thì có bộ đệm giữa hai process .
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 thì mình không biết ), thường có thực 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ờ chính sá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 giải trí trên chính sách nhận ra 3 kiểu của process :
Brownser process : trấn áp user interface, disk và network. Chỉ có duy nhất 1 process loại này .
Renderer process : gồm có phương pháp render / hiển thị một website. Mỗi lần bạn bật 1 tab mới, Chrome sẽ tự động hóa tạo 1 process loại này cho bạn. Renderer process chạy trên những sandbox, nghĩa là chúng không cho những process trên trình duyệt có năng lực tiếp cận ổ cứng, mạng lưới hệ thống mạng của người dùng, nhằm mục đích tăng độ bảo mật thông tin .
Plug-in process : hay còn gọi là extension trên trình duyệt, đây là loại process cần được tiếp xúc với hai loại process còn lại. ( Ví dụ : Flash )
Một process ( tiến trình ) trong hệ quản lý hoàn toàn có thể được triển khai độc lập hoặc tiếp xúc với nhau. Process độc lập là khi process không tác động ảnh hưởng hoặc bị tác động ảnh hưởng bởi những process khác trong mạng lưới hệ thống, và không san sẻ data với bất kể process nào. Process tiếp xúc khi process đó hoàn toàn có thể tác động ảnh hưởng hoặc bị ảnh hưởng tác động bởi những process khác trong mạng lưới hệ thống, và sự san sẻ data có diễn ra .
Thông thường, Inter Process Communication sẽ được hiện thực hóa, code trên những mạng lưới hệ thống máy tính song song ( parallel computer ), với những máy ảo nhỏ ( Virtual Private Server – VPS ), việc lập trình IPC là không thiết yếu. Stream Hub sẽ không nói về cách hiện thực IPC trong code mà nêu ra 1 số ít yếu tố tương quan đến IPC .
Nguyên Vũ
Website
Tôi có kinh nghiệm trong việc tạo ra những web vui vui phục vụ mục đích cá nhân và thoả mãn nhu cầu tìm kiếm thông tin từ người dùng. Tôi nhận ra nhiều trang web cung cấp thông tin chưa thực sự cá nhân hoá những thắc mắc của người dùng. Stream Hub là một sản phẩm “vui vui” tôi tạo ra có sứ mệnh giải quyết vấn đề đó.
Source: https://pokimobile.vn
Category: Hỏi Đáp