Message passing là gì

Một process (tiến trình) vào hệ điều hành hoàn toàn có thể được tiến hành chủ quyền hoặc tiếp xúc với nhau. Process độc lập là lúc process không tác động hoặc bị tác động bởi các process không giống trong hệ thống, với không share data với bất kì process nào. Process tiếp xúc khi process đó có thể tác động hoặc bị tác động bởi các process không giống trong hệ thống, và sự share data tất cả diễn ra.

Bạn đang xem: Message passing là gì

Thông thường, Inter Process Communication sẽ được hiện thực hóa, code trên những khối hệ thống máy tính tuy nhiên song (parallel computer), với số đông máy ảo nhỏ tuổi (Virtual Private server – VPS), việc lập trình IPC là không nên thiết. Stream Hub sẽ không còn nói về cách hiện thực IPC vào code mà lại nêu ra một số trong những vấn đề liên quan đến IPC.


Mục lục


Message-Passing Systems

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

Việc chất nhận được truyền data giữa những process (bạn hoàn toàn có thể tìm phát âm process là gì) là vì những tại sao sau:

Giúp chia sẻ thông tin giữa những users.Giúp speech up các tác vụ trong lắp thêm tính.Giúp chế tạo modun.Giúp dễ dàng trong chạy những tác vụ cùng một lúc.

IPC là viết tắt của trường đoản cú gì?

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

Hai models chính của IPC là shared memory (chia sẻ cỗ nhớ) – với trọng trách hình thành quanh vùng lưu trữ bộ nhớ lưu trữ chung – và message passing (truyền tin) – với trách nhiệm truyền download tin nhắn tiếp tục giữa các process.

Cả hai mã sản phẩm trên đều thịnh hành trong các hệ điều hành. Mã sản phẩm message passing bổ ích cho bài toán trao thay đổi số lượng nhỏ dại các data với dễ triển khai hơn vào hệ cơ sở dữ liệu phân tán – khối hệ thống phân tán (distributed system). Ngược lại, shared memory có thể cấp tốc hơn message passing do các hệ thống truyền thông điệp thường tiến hành thông qua system gọi (mà chúng tốn nhiều thời hạn hơn cùng phải gồm sự can thiệp của kernel – nhân hệ điều hành).

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

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

*
*

Shared-Memory Systems

IPC sử dụng mã sản phẩm shared memory sẽ có nhu cầu các process thâm nhập mở một vùng ghi nhớ chung. Vùng nhớ thông thường này được tạo nên thành từ không ít vùng ghi 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 add của vùng nhớ phổ biến ấy vào vùng nhớ riêng của bản thân mình . Nhưng mà thông thường, những hệ điều hành quản lý 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 chất nhận được việc truy hỏi cập bộ nhớ lưu trữ của nhau để có thể sử dụng với viết data trên vùng share chung. Những tiến trình sẽ ra quyết định kiểu data như thế nào được share và vùng chia sẻ chung sinh sống đâu. Tất nhiên chúng phải đảm bảo an toàn các vùng chia sẻ chung không trở nên ghi đè lên trên nhau.

Một ví dụ đơn giản và dễ dàng về việc ăn uống ở quán nạp năng lượng cho mã sản phẩm này. đưa sử, bạn gọi 10 phần ăn, các món nạp năng lượng được mang lên dần dần dần. Mang lại thức ăn là data phải truyền, người ăn uống là process cần data và đầu bếp là process cung ứng data. Việc đầu nhà bếp và người ăn uống cùng tiến hành nhiệm vụ của chính mình trong cùng thời gian để bảo vệ thời gian ăn không bị ngắt quãng cùng lâu. đó là cơ chế IPC. Và cụ thể hơn, chúng ta cùng share một lượng data/ thức ăn. Cùng với điều kiện, người ăn không được ăn (write data) lên phần mà lại đầu bếp chưa chế biến.

Vấn đề IPC trong khối hệ thống Shared Memory

Trong ví dụ về quán ăn ở trên, chúng ta có nhận thấy sự ko tốt? trả sử nếu nhiều thực khách cùng lúc order một món ăn, món ăn này sẽ ra sao? quay lại vấn đề trong khối hệ thống shared memory, nếu các processor cùng truy cập một vùng nhớ (memory) sẽ gây nên sai sót tính toán.

Nói một phương pháp “toán” hơn, nếu như ta khai báo x với cái giá trị ban đầu là 0. Cùng lúc processor 1 tăng biến x lên 1 với processor 2 tăng biến chuyển x lên 2, x sẽ có tác dụng là? Câu vấn đáp nếu processor làm sao chạy kết thúc sau, x sẽ sở hữu được giá trị đó; với đương nhiên chúng ta không thể biết được processor nào ngừng sau.

*
*

Hướng giải quyết và xử lý của vấn đề này là đồng điệu hóa (synchronising) shared data. Nghĩa là giả dụ processor đầu, sau, thuộc lúc đội giá trị thứu tự lên 1 với 2; thì giá bán trị sau cùng luôn luôn luôn là 3 (kệ thằng nào chuyển đổi giá trị sau cùng kết quả vẫn là 3 sau khi nhất quán hóa).

Message-Passing Systems

Bên cạnh việc dùng shared memory, một biện pháp khác nhằm liên kết các process lại cùng nhau là áp dụng message passing.

Message passing cung cấp một cơ chế được cho phép các quy trình liên lạc và đồng nhất mà ko cần share vùng lưu giữ (address space) của nhau. Điều này quan trọng đặc biệt hữu ích trong những hệ cơ sở dữ liệu phân tán (distributed database), khu vực mà những process ở trên những máy tính không giống nhau kết nối qua khối hệ thống mạng. Rõ ràng là lịch trình chat qua mạng internet như messenger được thiết kế với để người tiêu dùng kết nối với nhau trải qua việc trao đổi các tin nhắn.

Gửi (tin) nhận (tin)

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

Message-Passing Systems có 2 bí quyết thức: 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: từng process mong muốn truyền tin cần phải đặt tên mang đến tin nhắn hoặc tên người gửi

Symmetry: đề nghị cả tên fan gửi cùng tên tin nhắn để process đó thực hiện thao tác làm việc gửiAsymmertry: chỉ việc tên lời nhắn là process đó rất có thể gửi cho bất kể process như thế nào khác

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

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

Xem thêm: Riboxom Là Gì - Ribosome Liên Kết Là Gì

Hộp thư:Nơi lời nhắn được gởi vào hoặc được rước ra. Mỗi một vỏ hộp thư sẽ được khẳng định bởi 1 ID duy nhất. Những process hoàn toàn có thể liên lạc cùng với nhau thông qua nhiều vỏ hộp thư, tuy thế chỉ khi các hộp thư kia được thiết lập như vỏ hộp thư chung giữa nhị process.Kết nối được đồng nhất hoặc không được đồng điệu – blocking cùng nonblocking

o chặn gửi: process nhắn tin bị chặn cho tới khi lời nhắn đã được trao bởi process sót lại hoặc tới khi tin vào vỏ hộp thư.

o Không chặn gửi: process giữ hộ tin xong xuôi thì liên tục hoạt động.

o chặn nhận: Process thừa nhận tin chặn cho tới khi một tin nhắn bao gồm sẵn.

o Không ngăn nhận: process dìm tin sẽ nhận một tin hoàn chỉnh hoặc một cực hiếm null.

Dù là sử dụng Message Passing xuất xắc Shared-memory system, vẫn sẽ có được trường vừa lòng process A “đợi” process B có thông tin rồi mới thực hiện. Nếu những process thuộc “đợi”, đang dẫn cho timeout vô cùng lâu, bạn sẽ không hy vọng khi gửi gói tin/ gửi request và buộc phải đợi rất mất thời gian để có thể nhận data trả về, vậy gồm cách nào xung khắc phục tình trạng này? Đó chưa hẳn là quá trình mà chúng ta phải lo lắng, vày hệ quản lý điều hành đã thực hiện việc này cho việc đó ta, câu vấn đáp là bộ định thời.

*
*

Định thời CPU (Process Scheduling)

Mục tiêu của IPC nói trên là để các process không giống nhau có thể nhận thông tin của nhau, và nếu bạn có nhu cầu quá trình nhờ cất hộ – nhập được ra mắt đúng và chính xác, sẽ 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ông giống nhau) chạy xuyên suốt để tối đa hóa sử dụng CPU. Mục tiêu của việc phân tách sẻ thời gian là chuyển đổi CPU giữa những quá trình đó một cách thường xuyên để người dùng có thể tương tác với mỗi chương trình trong lúc nó hoạt động.

Một chương trình di chuyển giữa các hàng đợi khác nhau trong suốt thời gian của nó. Hệ điều hành 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 chọn lựa chương trình được tiến hành bởi một scheduler thích hợp.

Thông thường, vào một hệ thống, nhiều chương trình được chọn để coi xét rộng là hoạt động ngay lập tức. Những chương trình được lưu giữ trữ vào bộ nhớ của thiết bị (thông thường là ổ đĩa), đó là khu vực lưu trữ để hoạt động 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. Short-term scheduler hoặc CPU scheduler sẽ chọn từ những chương trình đã sẵn dàng để hoạt động và phân bổ CPU mang đến một vào số chúng

Sự khác nhau cơ bản giữa nhị bộ lập trình này nằm ở tần suất hoạt động. Short-term scheduler phải chọn một chương trình mới cho CPU thường xuyên. Mỗi chương trình có thể hoạt động chỉ vào vòng một vài phần nghìn giây trước khi chờ một yêu cầu I/O.

Thông thường, Short-term scheduler hoạt động tối thiểu mỗi 100 phần nghìn giây. Bởi vì những hoạt động như vậy, Short-term scheduler phải nhanh. Nếu tốn 10 phần nghìn giây để quyết định hoạt động một chương trình 100 phần nghìn giây thì 10/(100+10)=9 phần trăm CPU sẽ được dùng chỉ để lên kế hoạch (phần trăm 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: cỗ đệm cấm đoán phép bất kể tin nhắn ngóng nào, cũng có nghĩa là process nhờ cất hộ tin có khả năng sẽ bị chặn đến khi bên đó nhận tin.

o Bounded capacity: sẽ sở hữu một số lượng giới hạn n các tin nhắn được đợi trong buffer. Tức là nếu vẫn không tới giới hạn, các tin hoàn toàn có thể tiếp tục được tạo nên bởi process gửi tin. Nếu đã bao gồm n tin nhắn đang hóng được nhận, process này sẽ bị chặn cho đến lúc hàng tin nhắn được trống (bên kia dìm tin)

o Unbounded capacity: lượng tin nhắn chờ là vô tận, nghĩa là process gửi không lúc nào bị chặn.

Trường hòa hợp zero capacity thường xuyên được coi là trường hợp giữa hai process không có bộ nhớ lưu trữ đệm, còn hai trường hòa hợp bounded cùng unbound thì có bộ đệm giữa hai process.

*
*

Ví dụ thực tế của IPC – trình để mắt Chrome

Như các bạn đã biết, không giống như những trình chăm bẵm khác (ví dụ Firefox phiên phiên bản cũ, phiên bạn dạng mới thì mình ko biết), thông thường sẽ có tình trạng đứng 1 tab là đứng không còn cả trình duyệt. Tuy nhiên trình chuẩn y Chrome thì không như vậy.

Đó là nhờ chính sách multiprocess, từng tab của Chrome là một trong process hòa bình với nhau, với chúng luôn chạy đồng thời với nhau.

Kiến trúc multiprocess của Chrome chuyển động trên cơ chế nhận thấy 3 vẻ bên ngoài của process:

Brownser process: kiểm soát và điều hành user interface, disk và network. Chỉ gồm duy tốt nhất 1 process nhiều loại này.

Renderer process: bao hàm cách thức render/ hiển thị một trang web. Các lần bạn nhảy 1 tab mới, Chrome sẽ auto tạo 1 process nhiều loại này cho bạn. Renderer process chạy trên các sandbox, nghĩa là bọn chúng không cho các process trên trình duyệt có chức năng tiếp cận ổ cứng, khối 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 được gọi là extension bên trên trình duyệt, đấy là loại process buộc phải được giao tiếp với hai một số loại process còn lại. (Ví dụ: Flash)

Một process (tiến trình) trong hệ điều hành có thể được tiến hành hòa bình hoặc tiếp xúc với nhau. Process độc lập là lúc process không ảnh hưởng hoặc bị tác động bởi những process khác trong hệ thống, cùng không chia sẻ data với bất kỳ process nào. Process tiếp xúc khi process đó gồm thể tác động hoặc bị ảnh hưởng bởi các process khác trong hệ thống, cùng sự share data tất cả diễn ra.

Thông thường, Inter Process Communication sẽ tiến hành hiện thực hóa, code trên những hệ thống máy tính tuy nhiên song (parallel computer), với đa số máy ảo nhỏ (Virtual Private hệ thống – VPS), bài toán lập trình IPC là không buộc phải thiết. Stream Hub sẽ không còn nói về phong thái hiện thực IPC vào code nhưng mà nêu ra một số trong những vấn đề tương quan đến IPC.