Giáo trình Hệ điều hành phân tán (Phần 1)

ia xẻ như mã thực hiện lại mà mỗi luồng có stack cục bộ riêng của mình. Việc truy nhập vào buffer cùng được chia xẻ bởi các luồng cần loại trừ ràng buộc. Việc loại trừ ràng buộc có thể đạt được bằng cách sử dụng phương pháp đồng bộ bộ nhớ chia xẻ như semaphore hay bộ kiểm tra, vì tất cả các luồng chia xẻ một vùng địa chỉ. Hơn nữa đồng bộ luồng có thể hiệu quả hơn nhiều vì QT đồng bộ chỉ gọi phần cục bộ và có thể tránh được việc gọi nhân trong một số trường hợp. Các luồng trong ví dụ phục vụ trạm cuối này được tạo tĩnh và chạy không tiền định. Về cơ bản, chúng chạy giống như một bộ điều khiển ngắt thật sự. -Hình 3.4b, trình bày một tình huống ứng dụng luồng khác. Phục vụ File thi hành các thao tác dịch vụ file khác nhau theo yêu cầu từ khách. Một luồng được tạo ra cho mỗi thao tác và điều khiển được quay lại luồng chính, và như vậy luồng chính có thể tiếp nhận một yêu cầu mới. Trong những điều kiện nào đó, luồng được kết khối, và một luồng khác được lập lịch để thực hiện. Luồng ngừng tồn tại khi công việc của nó hoàn 68/249 thành. Kết khối luồng và lập lịch luồng được trình bày ở phần sau. Chú ý là trong ví dụ về phục vụ file, tồn tại luồng chính phục vụ như một trình điều phối công việc cho các dịch vụ file đồng thời; việc khởi tạo và kết thúc luồng là động. Tạo luồng và huỷ luồng là đơn giản vì lí do dùng lại không gian nhớ. Đây là cấu trúc luồng phổ biến cho phần lớn các loại phục vụ này. ? Ví dụ thứ 3 về luồng cho trong hình 3.4(c) là một khách đưa ra nhiều yêu cầu tới các phục vụ khác nhau. Đa luồng trong QT khách làm cho nó có thể đạt được đồng thời các dịch vụ và dị bộ thậm chí khi thông tin yêu cầu trả lời là đồng bộ. Một ứng dụng hữu dụng của cấu trúc này là việc cập nhật đồng thời các bản sao file nhân bản mà được quản lí bởi nhiều phục vụ file. Hỗ trợ luồng trong nhiều HĐH hiện đại rất rộng lớn bởi vậy người lập trình ứng dụng có thể viết các chương trình đồng thời một cách hiệu quả. Ví dụ, ứng dụng duyệt web đa luồng có thể khởi tạo việc truyền fie đa thành phần, cho phép làm chậm QT truyền file ở Internet chồng lên nhau. -Một ví dụ ứng dụng đa luồng khác là hệ thống đa cửa sổ. Các ứng dụng toạ độ cửa sổ trở nên dễ dàng hơn nếu chúng được thực hiện ở trong luồng với chia xẻ vùng địa chỉ logic chia xẻ. Chẳng hạn, một luồng có thể thực hiện một hoạt động trong cửa sổ này mà kết quả lại để trong một cửa sổ khác. Để thực hiện hiệu quả những ứng dụng này, các luồng ưu tiên và các hỗ trợ bộ đa xử lí được đòi hỏi. 69/249 Thi hành luồng trong không gian người dùng Hỗ trợ luồng như một gói thêm vào đã được thực hiện trên nhiều hệ thống bao gồm gói luồng DCE từ Tổ chức phần mềm mã mở OSF và gói QT nhẹ (LWP: Light Weight Process) từ Sun. Vấn đề thi hành cốt lõi là nắm giữ được các lời gọi hệ thống đang kết khối từ một luồng và lập lịch luồng để thực hiện trong một QT. Trong thi hành luồng trong không gian người dùng (chương trình người dùng), một QT được ấn định chia xẻ thời gian bộ xử lí như thường được làm trong bất cứ HĐH nào. Khoảng thời gian được ấn định này là đa thành phần giữa các luồng đang tồn tại. Các luồng chạy dựa trên thư viện hỗ trợ thời gian chạy luồng. Trách nhiệm của một thủ tục thời gian chạy luồng là thực hiện việc chuyển ngữ cảnh từ luồng này sang luồng khác. Mỗi lời gọi hệ thống kết khối từ một luồng đang thực hiện là không bị HĐH bẫy lỗi nhưng được gửi tới một thủ tục thời gian chạy. Thủ tục thời gian chạy sẽ đơn giản khi giữ lại TCB của luồng gọi và tải (nạp) TCB của luồng mà nó lựa chọn tạo thành các thanh ghi phần cứng (bộ đếm chương trình, các thanh ghi và các con trỏ stack) với giả thiết rằng nó được phép thực hiện như các thao tác đặc cách. Và kết quả, không một kết khối thực sự trong hệ thống xuất hiện nhưng một luồng bị kết khối trong hàng đợi được duy trì bằng thư viện hỗ trợ thời gian chạy, và sự thực hiện QT lại được tiếp tục với một luồng khác. Việc chuyển ngữ cảnh luồng yêu cầu một tải rất nhỏ vì nó bao hàm việc lưu giữ và khôi phục chỉ bộ đếm chương trình, các con trỏ stack. Hơn nữa, việc lập lịch chạy luồng được thực hiện bằng Thư viện thời gian chạy, người dùng có quyền lựa chọn mức ưu tiên tới luồng được tạo. Lập lịch cho luồng thông thường là theo không ưu tiên và dựa theo quyền ưu tiên vào trước thì phục vụ trước (FCFS - First Come First Served); Nó có thể là lập lịch có ưu tiên theo các mức khác nhau khi luồng mới được tạo có mức ưu tiên cao hơn. Sơ đồ có ưu tiên, chẳng hạn việc thực hiện cuộn (RR: Round Robin) các luồng sẽ khó hơn khi không sử dụng ngắt đồng hồ và thật sự là không cần thiết ở mỗi mức luồng. Nếu cần, một luồng có thể bao gồm nguyên thuỷ luồng ngủ hoặc nhường cho phép từ bỏ sự thực hiện của một luồng tới luồng khác nhằm tạo ra tính không đồng bộ chạy luồng. Các nguyên thủy luồng có trong các gói luồng điển hình là: -Quản lí luồng để thực hiện việc tạo luồng, tạm dừng, kết thúc luồng. -ấn định ưu tiên và các thuộc tính luồng khác. -Hỗ trợ đồng bộ và truyền thông chẳng hạn như semaphore, monitor, và CTĐ. Thi hành luồng trong không gian nhân của hệ điều hành Các gói luồng được thi hành như một mức phần mềm trong không gian người dùng là dễ thực hiện và cơ động mà không đòi hỏi phải thay đổi nhân. Luồng có thể được thi hành ở mức nhân với một số mở rộng. Khi thi hành luồng trong không gian nhân, việc kết khối và lập lịch luồng được xử lí như thông thường nhưng lại mềm dẻo hơn và hiệu 70/249 quả hơn. Ví dụ, luồng có thể được ưu tiên một cách dễ dàng, một luồng phát ra một lời gọi hệ thống thì nó có thể bị kết khối mà không kết khối các luồng khác thuộc cùng QT và mỗi luồng có thể hoàn thành một chu trình của bộ xử lí với cùng cơ sở của các QT. Tuy nhiên, sự trừu tượng hai mức tinh vi đối với đồng thời trở nên mờ nhạt hơn và lợi thế tải chuyển ngữ cảnh luồng của QT nhẹ không còn nữa. Tính cơ động và hai mức trừu tượng đồng thời đôi khi nảy sinh thêm bất lợi khác. Giống như các khái niệm mô hình Client/Server và RPC, luồng là khái niệm thiết kế hệ thống cơ bản. Việc lựa chọn thi hành luồng trong không gian nhân hay trong không gian người dùng là một nhân tố thiết kế hệ thống khó tính. Cách kết hợp thi hành luồng cả không gian người dùng và không gian nhân như trong Sun’s Solaris hội tụ được các lợi điểm của hai hướng tiếp cận trên. Phần dưới đây minh họa việc kết hợp hỗ trợ nhân đa luồng như vậy. Nhân truyền thống là những luồng đơn. Thường thì chỉ có một bộ xử lí và cấu trúc của nhận là rất gọn. Vì vậy, đòi hỏi dịch vụ nhân chạy trong một luồng đơn không cần tính sự ưu tiên. Không đồng bộ là điều cần thiết trong thao tác nhân. Gần đây, hai khuynh hướng quan trọng đã được nảy sinh cho những hệ thống hiện đại. Thứ nhất, máy tính đơn với nhiều bộ xử lý đã trở nên thông dụng. Thứ hai là sự phức tạp về nhu cầu phần mềm đòi hỏi phải tạo ra nhiều dịch vụ mới trong nhân. Nhân đa luồng hỗ trợ cho những dịch vụ nhân đồng thời đã được khẳng định. Thao tác nội tại của nhân và những dịch vụ mà nhân cung cấp tới ứng dụng của người dùng có thể được thi hành như luồng. Luồng trong không gian nhân đã được phức hợp trong một hệ đa bộ xử lý hạ tầng. Việc thực hiện luồng là song song thực sự và có thể định ưu tiên. Sự đồng bộ giữa những luồng trong nhân trở nên cần thiết và có thể thực hiện được bằng cách dùng bộ nhớ chia xẻ. Để kết hợp chặt chẽ luồng trong không gian người dùng và luồng trong không gian nhân trong cùng một hệ thống, Solaris giới thiệu một khái niệm luồng mức trung gian và gọi là QT nhẹ LWP. LWP được QT người sử dụng tạo ra và được chương trình con (trong thư viện) thời gian chạy luồng quản lý. Chúng được nhân tổ chức như là đơn vị cơ sở cho việc lập lịch. Luồng người dùng, không thể được nhân nhận biết, cũng được tạo ra và quản lý bởi bó luồng. LWP phục vụ giao diện luồng người dùng và luồng nhân. Hình 3.5 thể hiện nhân đa luồng có ưu tiên với ba mức đồng thời: Luồng của người sử dụng là đa thành phần theo LWP trong cùng một QT; LWP là đa thành phần theo luồng nhân và luồng nhân là đa thành phần trong hệ đa bộ xử lý. 71/249 Luồng người dùng có thể được lập lịch tới bất cứ một LWP nào được QT tạo ra. Khi được gắn tới một LWP, nó trở thành thực hiện được khi dùng thời gian được nhân đã định vị tới LWP. Mỗi LWP lại được kết nối tới một luồng nhân. Lời gọi kết khối từ một luồng người sử dụng sẽ bẫy tới một LWP. LWP đó tạo ra một hệ thống thực gọi đến nhân và trở thành kết khối. Việc kết khối LWP không làm kết khối toàn bộ QT do các luồng đợi có thể được lập lịch tới LWP khác trong cùng QT. Luồng người dùng có thể được ưu tiên vì rằng các LWP có thể được ưu tiên bởi nhân. Việc thi hành lai có tính mềm dẻo và hiệu quả từ cả luồng người dùng và luồng nhân. Rất nhiều HĐH hiện thời có hỗ trợ luồng và có một số lượng lớn các phần mềm sử dụng luồng. Sự hỗ trợ luồng trở thành một bộ phận trong HĐH ngày nay. 72/249 73/249 Mô hình đồ thị thể hiện các quá trình và các dịch vụ thời gian Mô hình đồ thị thể hiện các QT Mô hình đồ thị Đoạn 3.1 mô tả các khái niệm QT và luồng. Trong đoạn này, chúng ta quan tâm đến việc làm thế nào để chúng có thể đặt cùng với nhau. Các QT có quan hệ với nhau bởi điều đó cần thiết cho: - tính đồng bộ: việc chạy một vài QT phải được tiếp nối theo một trình tự nào đó. Một ví dụ về sự đồng bộ là mối quan hệ đi trước (tiền tố: predecence) giữa hai QT. Mối quan hệ đi trước giữa hai QT quy định rằng một QT chỉ được thực hiện khi mà những QT "đi trước" nó đã được thực hiện. - hoặc/và vấn đề truyền thông: Trong nhiều trường hợp thì mối quan hệ đi trước hoặc thứ tự của các QT là không nhất thiết đối với việc các QT CTĐ cho nhau. Hình 3.6 sử dụng mô hình đồ thị để biểu thị hai cái nhìn khác nhau về sự tác động giữa các QT. Đồ thị QT đồng bộ theo mô hình đồ thị có hướng không chu trình thể hiện trực tiếp mối quan hệ đi trước và thứ tự trong tập các QT. Những cạnh vô hướng trong đồ thị QT dị bộ thể hiện đường truyền thông và sự phụ thuộc giữa các QT. Các đồ thị trong hình 3.6 chưa cho biết cụ thể thực sự mô phỏng tác động trong một hệ phức tạp. Tuy nhiên, chúng vẫn được sử dụng để xây dựng mô hình các QT và bộ xử lý trong hệ thống phân tán: - Đồ thị QT đồng bộ được sử dụng để đánh giá tổng thời gian của một tập hợp các QT, - Đồ thị truyền thông dị bộ có thể được sử dụng để nghiên cứu phân bố các bộ xử lí nhằm tối ưu hoá tổng chi phí về thời gian truyền thông giữa bộ xử lí. Đồ thị quá chi tiết đối với hệ phân tán thường làm cho việc phân tích khó khăn hơn và thậm chí gần nhưng không thể giải quyết được. Trong hình 3.6, cạnh có hướng trong đồ thị đi trước được giải thích qua truyền thông đồng bộ đối với QT gửi và nhận TĐ. Kết quả từ QT này được chuyển đến QT liền sau nó như là một input. Sự chuyển thông tin xẩy ra và được đồng bộ chỉ khi hoàn thành một QT và bắt đầu một QT tiếp theo. 74/249 Truyền thông được xác định chính xác hơn trong đồ thị QT dị bộ, khi chưa thể nói về việc làm thế nào và vào lúc nào thì việc truyền thông xẩy ra, ngoại trừ việc khẳng định tồn tại đường truyền thông giữa hai QT. QT trong đồ thị vô hướng thực hiện vô hạn định, trái lại, QT trong đồ thị có hướng thì chỉ có thể thực hiện trong một khoảng thời gian nhất định và được gọi là thời gian sống (lifetime). Có ba kiểu CTĐ cho mô hình đồ thị dị bộ: Một chiều (one-way), Client/ Server và ngang hàng (peer to peer). Nếu sử dụng thuật ngữ về truyền tin thì chúng tương đương với: truyền đơn (simple), Bán - hai chiều (Half - duplex) và hai chiều (full - duplex): - Một QT ứng dụng CTĐ một chiều thì gửi một TĐ nhưng không có yêu cầu về sự trả lời. Ví dụ về truyền tin loại này là thông tin quảng bá (broadcast) cho mọi người mà không có sự kiểm tra từ mọi người về kết quả nhận TĐ. - Trong mô hình Client/Server, truyền thông hai chiều: Một QT gửi yêu cầu và nhận sự trả lời đối với yêu cầu đó. Rất nhiều ứng dụng thực hiện theo quan hệ hai chiều master/ slave. - Thông tin ngang hàng là một cách trao đổi thông tin đối xứng, nó được sử dụng cho việc chuyển thông tin giữa những qúa trình cộng tác. Mô hình không gian - thời gian Mô hình đồ thị QT đồng bộ và dị bộ thích hợp cho việc đánh giá hệ thống nhưng lại thiếu chi tiết và đầy đủ để thể hiện được sự tương tác giữa các QT. Hình 3.7 trình bày mô hình không gian - thời gian là cách thể hiện tốt hơn việc truyền thông và quan hệ đi trước. Sự tồn tại của đường truyền thông và quan hệ đi trước giữa các sự kiện và việc truyền thông thực sự được thể hiện tường minh trong mô hình. Quan hệ đi trước hoặc là đường truyền thông tin được nhận biết dễ dàng trong mô hình không gian - thời gian. Mô hình QT này có nhiều thông tin để đánh giá sự tương tác giữa các QT hơn là thông tin để đánh giá về sự hoạt động chung toàn hệ thống. 75/249 Như vậy, mỗi mô hình (đồ thị, không gian - thời gian) có tác dụng riêng và tùy thuộc vào mục đích đánh giá để chọn mô hình. Khi các QT được thể hiện bằng đồ thị đi trước hoặc đồ thị truyền thông, sự tương tác giữa các QT phải được phát biểu trong một ngôn ngữ hoặc theo các kiểu kĩ thuật khác nhau. Giải pháp hoặc đặt ra một ngôn ngữ đồng thời (concurrent language)cho QT đồng thời hoặc là sẽ dễ dàng hơn khi mở rộng một ngôn ngữ tuần tự đã có bằng cách bổ sung những cấu trúc hoặc thêm một HĐH cung cấp cho việc tạo QT, truyền thông, và đồng bộ QT. Ví dụ, chúng ta đưa ra một cấu trúc điều khiển Cobegin/Coend hoặc sử dụng những lời fork/join để tạo và đồng bộ những QT đồng thời. Những QT được tạo ra bằng cách này thì được ghép chặt chẽ khi chúng có mối quan hệ chủ tớ (master/slave) hoặc là cha con (parent/child) và chia sẻ cùng một thuộc tính chung. Chúng có thể phối hợp làm việc vì một mục tiêu chung và thường được thực hiện bởi một cá thể riêng hoặc là một tổ chức nào đó. Giải pháp đó thích hợp cho việc thực hiện mô hình đồ thị đi trước. Nhưng về lâu dài, giả sử mối quan hệ giữa các QT là ngang hàng. QT chỉ tác động cùng với QT khác thông qua truyền thông liên QT. Không có mối quan hệ đi trước giữa các QT. Trong thực tế, các QT được tạo lập một cách độc lập, chạy dị bộ và có khoảng thời gian sống khác nhau. Mô hình tốt nhất là đồ thị QT truyền thông. Trong trường hợp này, sự xác định và tương tác giữa các QT phát triển thành một HĐH thay vì thành một ngôn ngữ lớn. Mô hình Client/Server Một cách mô tả tác động lẫn nhau giữa các QT là mô tả theo cách các QT nhìn nhau. Mô hình phổ biến nhất là mô hình Client/Server (quan trọng gần như khái niệm trong suốt trong hệ phân tán). Mô hình Client/Server là hình mẫu lập trình thể hiện tương tác giữa các QT và cấu trúc hệ thống. Mọi QT trong hệ thống cung cấp những dịch vụ cho 76/249 / hoặc yêu cầu dịch vụ từ các QT khác. QT đưa ra yêu cầu phục vụ được gọi là khách, QT cung cấp dịch vụ được gọi là phục vụ. Đối với mỗi tương tác, một QT chỉ có thể là khách hoặc phục vụ. Tuy nhiên, trong nhiều trường hợp, QT có thể đóng vai trò cả khách lẫn phục vụ. Tương tác giữa khách và phục vụ thông qua dãy yêu cầu và trả lời. QT khách yêu cầu dịch vụ từ phục vụ và tự khoá bản thân lại. Phục vụ nhận được yêu cầu từ khách, thực hiện thao tác cần thiết và sau đó gửi TĐ trả lời cho khách. Khi có kết quả trả lời từ phục vụ, khách lại bắt đầu tiếp tục thực hiện. Điều cơ bản ở đây là đồng bộ hỏi - đáp để trao đổi thông tin. Về mặt logic thì khách truyền thông trực tiếp với phục vụ nhưng thực tế thì yêu cầu hoặc trả lời phải đi qua phần nhân gửi, thông qua một mạng truyền thông đến nhân đích và QT đích. TĐ không được thông dịch bởi hệ thống. Giao thức truyền thông mức cao giữa khách và phục vụ có thể xây dựng trên những TĐ yêu cầu và TĐ trả lời. Hình 3.6 minh họa khái niệm mô hình Client/Server đối với tương tác QT. Mô hình truyền thông Client/Server Truyền thông RPC Truyền thông CTĐ Dịch vụ truyền TĐ hướng kêt nối hoặc không có kết nối Hình 3.9. Kiểu truyền thông Client/Server trên RPC và CTĐ 77/249 Mô hình Client/Server có thể được hiểu như một mô hình truyền thông hướng dịch vụ. Đây được coi là mức trừu tượng cao của sự truyền thông liên QT, mà sự truyền thông này có thể được cung cấp (hỗ trợ) bởi hoặc là RPC hoặc truyền thông CTĐ (message passing comminucation) lần lượt được thi hành qua dịch vụ giao vận theo hướng kết nối hoặc không kết nối trong mạng. Hình 3.9 cho biết quan hệ của 3 khái niệm trên đây: mô hình Client/Server, RPC và CTĐ. Những dịch vụ được cung cấp bởi phục vụ có thể theo hướng kết nối hoặc không kết nối. Một dịch vụ hướng-kết nối có thể lại được xây dựng dựa trên dịch vụ không kết nối. Nhưng điều ngược lại thì không thể. Mô hình Client/Server đã đạt được một độ trong suốt trong truyền thông. Chương II đã giới thiệu hệ thống dịch vụ trong hệ phân tán bao gồm ba khu vực chính, đó là : Nguyên thuỷ, hệ thống và dịch vụ gia tăng giá trị. Dịch vụ nguyên thuỷ là cơ chế nền tảng được đặt trong nhân. Từ góc độ ứng dụng thì chỉ có dịch vụ hệ thống và dịch vụ gia tăng giá trị là có thể nhìn thấy (có thể sử dụng) được từ phía người dùng. Đối với người sử dụng thì chương trình là một tập hợp của những (QT) khách và phục vụ. Nếu chúng ta thi hành dịch vụ hệ thống như là QT phục vụ và tách nó ra khỏi nhân với mọi trường hợp có thể được thì kích thước của nhân sẽ được giảm một cách đáng kể. Rõ ràng là nếu như kích thước của nhân được giảm xuống thì tính khả chuyển theo nền phần cứng khác nhau là dễ dàng hơn. Một kết quả tự nhiên là sử dụng mô hình Client/ Server là QT chỉ cần một kiểu lời gọi hệ thống đến nhân đơn, chính là lời gọi gửi và nhận yêu cầu. Vì vậy, nhân không cần thiết phải phân tích cú pháp lời gọi hệ thống và xác định cái gì cần phải làm. Thay vào đó, trách nhiệm của QT phục vụ là thông dịch thông điệp theo hiểu biết nhiều nhất của nhân về cấu trúc của TĐ. Giao diện giữa QT và nhân trở nên đơn giản và đồng nhất. Nhiều phục vụ có thể cùng tồn tại nhằm cung cấp cùng một dịch vụ. Chúng cần được định danh hoặc theo tên hoặc theo chức năng mà chúng cần thực hiện. Đòi hỏi này phục vụ việc định vị các phục vụ. Những phục vụ, được gọi là những phục vụ ràng buộc hay phục vụ đại lý, chúng ràng buộc QT khách với những QT phục vụ được chọn thành cặp, đôi khi chúng cũng cần được định vị. Cuối cùng, cần hạn chế một cách tối thiểu các phục vụ mà hoàn toàn đã biết tên hoặc địa chỉ. Khi có yêu cầu từ phía khách, phục vụ ràng buộc có thể chọn phục vụ nào thích hợp nhất cho khách đó hoặc là một phục vụ nào đó làm cân bằng tải đối với các phục vụ. Như một sự lựa chọn, cũng có thể thực hiện việc xác nhận của khách cho phục vụ. 78/249 Các dịch vụ thời gian Mô hình không gian - thời gian tường minh tương tác giữa các QT, các sự kiện là được ghi nhận chi tiết theo đồng hồ của riêng QT đó. Trong thực tế thì đồng hồ thường được sử dụng để thể hiện thời gian (một độ đo tương đối về thời gian so với một điểm thời gian làm mốc) và bộ đếm thời gian (một độ đo tuyệt đối cho khoảng thời gian) được dùng để mô tả tính đồng thời của các sự kiện theo ba cách khác nhau: 1. Khi nào thì sự kiện xuất hiện. 2. Sự kiện xuất hiện trong bao lâu. 3. Sự kiện nào xuất hiện trước nhất. Đối với các ứng dụng máy tính, chúng ta cần ý niệm rõ ràng về thời gian và đo thời gian. Ví dụ chúng ta cần biết một file đã được sửa đồi lần cuối cùng vào lúc nào, một khách được đặc quyền bao lâu để truy nhập phục vụ và sửa đổi nào của đối tượng dữ liệu là xẩy ra đầu tiên. Trong trường hợp thể hiện thời gian bằng đồng hồ được tăng một cách đều đặn thì không có sự nhập nhằng về sự xuất hiện các sự kiện trong một QT. Tuy nhiên, những QT tương tác trên những máy độc lập riêng rẽ có thể có nhận thức khác nhau về thời gian. Do không thể có sự nhất thể về đồng hồ toàn cục nên rất khó khăn phối hợp các hành động phân tán như thu lượm thông tin rác trên mạng, định kỳ bảo quản hệ thống file vào nửa đêm mỗi ngày hoặc việc xác nhận giá trị thời điểm kết thúc của việc nhận TĐ. Trong phần này sẽ mô tả hai khái niệm nền tảng về thời gian để xác định được thời gian trong hệ thống phân tán: Đồng hồ vật lý và đồng hồ lôgic. Đồng hồ vật lý là một xấp xỉ tốt của thời gian thực, được dùng để đo cả về thời điểm và lẫn khoảng thời gian. Đồng hồ logic được dùng để sắp xếp các sự kiện. Cả hai đều có vai trò quan trọng trong hệ phân tán. Đồng hồ vật lý Trong mọi hệ thống máy tính, đồng hồ vật lý (physical clocks) được sử dụng để đồng bộ và lập lịch cho các hoạt động của phần cứng. Mặt khác, theo khía cạnh phần mềm, nó cần thiết để mô phỏng thời gian thực hoặc là đo khoảng thời gian. Bộ đếm thời gian phần mềm dựa vào bộ đếm thời gian phần cứng. Trong hệ phân tán, mỗi đồng hồ chạy theo một nhịp riêng của mình, và vì vậy tồn tại một độ trễ trong việc trình diễn đồng hồ thời gian. Vì thông tin về thời gian không thể chuyền và nhận được một cách tức thời, do đó, một đồng hồ vật lý tuyệt đối theo lý thuyết thì không thể có. Vì vậy, chúng ta phải đặt một cái ổn định xấp xỉ thời gian thực toàn cục. Thách thức đặt ra là làm sao cho mọi máy tính có thể nhận được thời gian đồng nhất. Mong muốn có thể đạt thời gian đồng nhất gần với thời gian thực nhất có thể được. Để giải quyết vấn đê trên đây, cần một thuật toán về đồng bộ đồng hồ. Hình 3.10 thể hiện kỹ thuật dịch vụ thời gian gần giống với dịch vụ thời gian phân tán DTC (distributed time service) có trong DCE. Bộ 79/249 ghi nhận thời gian (TC) trong mỗi máy khách yêu cầu dịch vụ thời gian tới một hoặc nhiều phục vụ thời gian (TS). Phục vụ thời gian lưu giữ những thông tin thời gian mới nhất và có thể truy cập đến nguồn thời gian thực toàn cầu. Phục vụ thời gian có thể trao đổi thông tin thời gian, vì vậy dịch vụ thời gian cua nó có thể thích hợp với những khách của nó. Tồn tại hai vấn đề cần quan tâm trong thực tế trong thi hành dịch vụ thời gian, đó là độ trễ trong việc ghi nhận thông tin về thời gian phải được bù vào và sự khác nhau giữa các nguồn thời gian phải được định cỡ. Phần bù độ trễ Hình 3.10 mô tả ba kiểu của truy cập thời gian: Phục vụ thời gian đến nguồn thời gian toàn cầu, khách đến phục vụ thời gian và phục vụ thời gian lẫn nhau. Nhiều nguồn hệ thống thời gian toàn cầu UTC (Universal Coordination Time) chuẩn có sẵn đối với máy tính và những ứng dụng gắn chặt tới thời gian khác. Viện tiêu chuẩn và Công nghệ quốc gia NIST của Mỹ cung cấp cách truy nhập với độ chính xác lên tới một miligiây. Dịch vụ thời gian máy tính tự động ACTS (Automated Computer Time Service) cung cấp những dịch vụ modem tới thời gian NIST thông qua đường điện thoại. ACTS được thiết kế cho những ứng dụng chỉ yêu cầu những dịch vụ thời gian không thường xuyên: QT quay số modem là quá chậm đối với việc đồng bộ những hoạt động phần cứng. Đối với những truy nhập mang tính thường xuyên, NIST thực hiện một trạm phát sóng ngắn WWV thực hiện việc tán phát những tín hiệu UTC. Độ trễ thời gian của TĐ có thể được tính toán một cách chính xác nếu như khoảng cách từ trạm phát sóng và khoảng cách đến điểm truyền thông tin là được biết. Tuy nhiên, điều không may là sóng radio lại rất nhạy cảm với môi trường. Một phương án khác là sử dụng dịch vụ của hệ thống định vị toàn cầu GPS (Global Positioning System). Tuy nhiên, vệ tinh GPS lại có quỹ đạo chậm và khoảng cách của nó đến trái đất cũng thay đổi theo thời gian. Để tính được chính xác độ trễ (hoặc khoảng cách) có thể thì cần đến sự theo dõi của nhiều vệ tinh GPS. Giá thành cho phần cứng cũng như giá thành liên quan đến việc tính toán sẽ là rất cao. Cũng có thể dựa vào trạm vệ tinh để quảng bá các thông tin UTC. Khoảng cách vệ tinh đến trạm máy tính dưới đất thì hoàn toàn cố định nhưng độ trễ tốc độ truyền thì lại rất lớn, khoảng 125 milli giây. Nhiều kênh truyền hình cáp (Cable TV chanel) cũng mang cả thông tin về thời gian trong tần số. Mọi nguồn thời gian toàn cầu (Universal time source) chứa đựng những lập luận tán thành và phê phán trong đó. Rất may là không phải tất cả các phục vụ thời gian cần truy nhập đến UTC từ những nguồn đó mà một phục vụ thời gian có thể truyền bá thời gian UTC hiện tại được nó nắm giữ đến những phục vụ thời gian khác một cách chính xác và nhanh chóng. 80/249 Vấn đề độ trễ trong QT trình diễn hoặc thu nhận thông tin UTC từ phía khách của một phục vụ thời gian lại là một vấn đề khác. Thêm vào độ trễ của QT truyền tín hiệu là độ trễ trên đường truyền thông mạng. Độ trễ trên mạng thay đổi thường xuyên và là một vấn đề đáng quan tâm hơn là độ trễ truyền tín hiệu. Giả sử Ts và Tr là thời gian gửi và nhận được những yêu cầu về dịch vụ thời gian từ khách đến phục vụ thời gian. Giả sử tp là thời gian gian cần thiết để dịch thời gian thực hiện yêu cầu đó. UTC từ phục vụ thời gian trả về cho khách có thể được điều chỉnh cho đúng bằng cách cộng thêm một nửa của độ trễ Tr - Ts - tp. Công thức tính sự bù đó dựa trên giả thiết là QT giao thông trên mạng (network trafic) là đối xứng. Nếu đồng hồ ở máy khách nhanh hơn UTC mới thì nó sẽ được làm chậm lại bằng phần mềm. Đồng hồ thời gian không thể quay lại được vì điều đó phủ nhận thời gian của các sự kiên trước đó. Vấn đề đồng hồ chậm hơn thì không đáng ngại nhưng tốt nhất là tăng tốc độ đồng hồ để nó đạt được cùng với UTC một