Tổng quan về giao tiếp liên tiến trình - Interprocess communication (IPC)
Linux
99
White

BeanRedArmy viết ngày 29/10/2018

Tổng quan về giao tiếp liên tiến trình - Interprocess communication (IPC)

1. Phân loại các công cụ giao tiếp tiến trình

alt text

Ta có thể chia các công cụ được sử dụng trong IPC thành 3 loại chính:

  • Communication: Dùng để trao đổi dữ liệu giữa các process.
  • Synchronization: Hoạt động đồng bộ giữa các process.
  • Signal: Mặc dù signal sinh ra với mục đích khác, nhưng ta vẫn có thể sử dụng chúng như một công cụ đồng bộ trong một vài tình huống. Hoặc hiếm hơn là sử dụng signal như công cụ giao tiếp: signal number được coi như là một thông tin.

Ngoài ra trên hình, ta còn có thể thấy rằng có một số công cụ thực hiện những chức năng IPC tương tự nhau, lý do là:

  • Mỗi trong các công cụ tương đương nhau thì được phát triển cho một biến thể của Unix. Ví dụ FIFOs được dev trên System V còn (stream) sockets được dev trên BSD.
  • Những công cụ tương tự mới được tạo ra để giải quyết những thiếu sót của những công cụ cũ. Ví dụ như POSIX IPC (message queue, semaphore, shared memory) được thiết kế để cải thiện cái cũ là System V IPC.

Trong một số trường hợp, các công cụ trong cùng một nhóm ở hình trên thực ra cung cấp những chức năng tương đối khác nhau. Ví dụ như stream socket có thể được sử dụng để giao tiếp qua mạng, trong khi FIFO chỉ để sử dụng với các process trên cùng một máy.

2. So sánh các công cụ IPC

Khi đề cập đến IPC, các lập trình viên phải đối mặt với rất nhiều lựa chọn, và điều đó dường như làm chúng ta bối rối. Ta sẽ xem xét một vài yếu tố để việc chọn lựa các công cụ IPC trở nên rõ ràng hơn.

Định danh các đối tượng IPC và handle IPC

Để truy cấp các đối tượng IPC, một process phải biết đến một đối tượng định danh IPC đó, và khi đối tượng đó được opened, tạo ra một handle, process kia sẽ xử lý trên đối tượng handle này.
Bảng sau sẽ làm rõ:
alt text

Ví dụ: Khi ta làm việc với System V semaphore. Ta phải cung cấp cho hàm semget() một định danh là key. Hàm semget sẽ trả về một handle là một số nguyên semid chẳng hạn. Về cơ bản thì hàm semget() chỉ trả về duy nhất 1 giá trị như nhau với một định danh key. Sau này mọi thao thác trên semaphore đều là thao tác với semid.
Ta có thể thấy có một số công cụ dùng định danh là một đường dẫn, một số dùng key, vân vân. Còn handle thì có thể là file descriptor hoặc identifier hoặc pointer...

Chức năng

Sự khác nhau đầu tiên giữa các loại IPC là mục đích sử dụng chúng, dẫn đến chức năng cũng khác nhau.

  • Các công cụ data-transfer luôn bao gồm các thao tác đọc và ghi. Luồng điều khiển giữa ghi và đọc, cũng giống như việc đồng bộ ( reader sẽ bị block khi đọc dữ liệu từ một nơi đang trống) được kiểm soát tự động bởi kernel.
  • Shared memory thì cho phép một process chia sẻ dữ liệu bằng cách cho các process khác có thể thấy được vùng nhớ mà nó chia sẻ. Các thao tác trên nó đơn giản là truy cập vào vùng nhớ, cũng giống như truy cập bộ nhớ trên vùng địa chỉ ảo của process. Tuy nhiên việc kiểm soát đồng bộ thì phải tự lập trình, dẫn đến sự phức tạp trong thiết kế.

Tính khả chuyển

Các hệ điều hành UNIX hiện đại hỗ trợ hầu hết các công cụ IPC trong hình ở đầu bài. Tuy nhiên, các công cụ POSIX IPC (message queue, semaphore, shared memory) lại không được sử dụng rộng rãi như System V IPC, đặc biệt ở những hệ thống UNIX cũ. Do đó trên quan điểm về tính khả chuyển thì System V IPC có lợi thế hơn POSIX IPC. Tuy nhiên...

Vấn đề trong thiết kế của System V IPC

Các công cụ System V IPC được thiết kế một cách độc lập so với mô hình I/O truyền thống của UNIX. Những POSIX IPC tương ứng được thiết kế để giải quyết vấn đề này:

  • Các công cụ System V IPC không có tính kết nối. Thực chất kernel sẽ không ghi lại được việc một process có đang thao tác với một handle IPC hay không. Ví dụ như với System V semaphore, ta lấy được handle là một số nguyên: semid từ hàm semget. Chỉ có process chứa semid thao tác với semid, còn kernel sẽ không quản lý được handle này. Có nghĩa là kernel không thể duy trì được biến đếm số lượng các process đang sử dụng object. Hệ quả là phải đòi hỏi phải lập trình tốt thì mới có thể biết khi nào object có thể được xóa một cách an toàn.
  • Lập trình với System V IPC khác biệt với mô hình I/O truyền thống của UNIX ( System V IPC sử dụng key và IPC identifier thay vì đường dẫn và file desriptor), do đó trở nên phức tạp hơn.

Ngược lại với POSIX IPC, kernel được viết về biến đếm số lượng các process đang thao tác với công cụ IPC. Do đó việc đảm báo object được xóa an toàn trở nên dễ dàng hơn. Ngoài ra các hàm thao tác với POSIX IPC cũng quen thuộc như với mô hình UNIX truyền thống.

Khả năng truy cập và thời gian tồn tại của các object IPC

Được tóm tắt trong bảng sau:
alt text

Một số đối tượng của công cụ IPC có khả năng truy cập được quy đinh bởi permission mask ( quyền truy cập dành cho owner, group và other), các mask này được thiết lập khi đối tượng được tạo. Một số khác lại thì quyền truy cập lại chỉ được cấp cho những process liên quan, điển hình như pipe hoặc anonymous mapping. Với pipe và anonymous mapping, chỉ có process tạo ra object và các process con được fork() ra mới biết đến sự tồn tại của object, do đó hiển nhiên những process không liên quan không thể truy cập tới những object này.

Persistence ám chỉ đến thời gian tồn tại của object. Process persistence có nghĩa object sẽ chỉ tồn tại đến khi còn ít nhất một processs giữ nó. Nếu object bị đóng bởi tất cả các process, những tài nguyên liên quan đến object sẽ được giải phóng. Pipe, FIFOs và socket là những ví dụ điển hình. (Chú ý là FIFOs có sự khác giữa thời gian tồn tại của object và thời gian tồn tại của dữ liệu , dữ liệu của FIFO sẽ được lưu trên file system và sẽ tồn tại cho dù tất cả những file descriptor của FIFO bị đóng).
Kernel persistence có nghĩa là object sẽ tồn tại cho đến khi nó bị xóa một cách tường minh hoặc hệ thống bị tắt mà không phụ thuộc đế bất khi process nào giữ chúng. Ví dụ một process có thể tạo ra một object IPC, ghi dữ liệu vào nó và đóng nó. Sau đó một process khác có thể mở lại object và đọc data vừa được ghi vào.
File-system persistence nghĩa là object sẽ tồn tại cùng với file system chỉ cho đến khi nó bị xóa tường minh. Chỉ có memory-mapped file là tồn tại theo dạng này.

Hiệu năng

Về bản chất, các công cụ IPC vẫn có sự khác biệt về hiệu năng, tuy nhiên:

  • Hiệu năng của một công cụ IPC không phải là yếu tố then chốt trong việc lựa chọn.
  • Hiệu năng của một công cụ IPC lại có thể khác nhau giữa các hệ thống UNIX hoặc các phiên bản linux kernel.
  • Quan trọng nhất, hiệu năng của một công cụ IPC sẽ phụ thuộc vào cách dùng ( cách lập trình) cũng như môi trường mà nó được sử dụng. Những yếu tố liên quan đến bao gồm kích thước data được trao đổi bằng IPC, ...

BeanRedArmy 22-10-2018

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

BeanRedArmy

11 bài viết.
24 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
7 2
Device Tree trong Linux Device Tree (DT) là một file mô tả phần cứng, có kiểu định dạng giống JSON, nó mô tả một cấu trúc cây, ở đó thì các device...
BeanRedArmy viết 9 tháng trước
7 2
White
4 0
Context trong Linux Process context, interrupt context, user(space) context, system call context, atomic context, nonatomic context,... là những k...
BeanRedArmy viết 11 tháng trước
4 0
White
4 0
Reentrant và Threadsafe Một chương trình máy tính, một hàm A hoặc một chương trình con được gọi là reentrant nếu nó có thể bị ngắt lúc đang thực t...
BeanRedArmy viết 10 tháng trước
4 0
Bài viết liên quan
White
1 0
sudo du sh
t viết hơn 3 năm trước
1 0
White
35 10
Thời kỳ mới đi làm tôi nghĩ cứ phải gõ thật nhiều cho quen cho nhớ nhưng lâu dần việc đó cho cảm giác thật nhàm chán. Hiện giờ, những gì tôi hay là...
manhdung viết hơn 4 năm trước
35 10
White
1 0
Sử dụng option I với xargs Với option I thì bạn có thể sử dụng place holder với biến được lấy ra từ xargs man của option này: I replacestr R...
LinhPT viết hơn 3 năm trước
1 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
11 bài viết.
24 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!