Mục đích của DIS là cung cấp một phương pháp mã hoá dữ liệu nhanh chóng, đơn giản, gọn nhẹ và độc lập với định dạng của máy cho việc mã hoá dữ liệu về dạng xâu ký tự và ngược lại. Bởi vì dữ liệu có thể được giải mã trực tiếp ở chính cấu trúc nội tại của nó nên các thao tác sao chép dữ liệu sẽ được giảm đi. Mặt khác một lợi ích nữa là chúng ta cũng có thể đọc được các dữ liệu này.
Theo cách này dữ liệu được biểu diễn theo đúng những gì chúng ta nhìn thấy về chúng nhưng đi kèm với độ dài của mỗi phần tử được mã hoá. Một nhược điểm của phương pháp này là với một số nguyên dương nhỏ chúng ta không thể nói là đấy là số dạng signed hay unsigned chars, short, ints or long sau khi chúng ta đã biết dạng mã hoá của nó. Tương tự như vậy cho một số âm nhỏ, chúng ta chỉ có thể xác định duy nhất một điều là dữ liệu ban đầu không phải là số không dấu. Và ở đây cũng không xác định trước được độ dài của từ một từ mã và phương pháp mã hoá, có thể dùng mã bù hai, mã bù một, số lớn thậm chí là mã nhị phân.
Với phương pháp này mọi dữ liệu cơ sở của C đều có thể được quản lý. Cụ thể singned và unsigned chars, short, ints, longs tạo nên tập số nguyên. Ký tự NULL cùng với xâu ký tự tạo nên xâu ký tự với ký tự NULL dùng để báo kết thúc xâu. Floats, doubles và long doubles tạo nên tập số thực
Các loại dữ liệu phức tạp khác phải được xây dựng từ những dữ liệu cơ sở.
Mẫu mã hoá một số nguyên :
integer =: <count><sign><decimal string> | <count><integer> count =: <decimal string>
sign =: ’+’ | ’-’
decimal string =: <digit> | <digit><decimal string> digit =: ’0’ | ’1’ | ’2’ | ’3’ |’4’ | ’5’ | ’6’ | ’7’ | ’8’ | ’9’
Trên đây là công thức chung, với số chỉ có một chữ số thì thành phần
count là không có mà chỉ có hai thành phần dấu và giá trị. Các trường hớp còn thì count là độ dài của số đó, thành phần decima string giá trị thực của số đó
Chúng ta sẽ giải thích thêm ở số cuối cùng :
Số 2 là số chữ số của số tiếp theo sau nó, tiếp sau số 2 là số 10 có hai chữ số, và bởi vậy số 10 biểu diễn giá trị 10 trong hệ thập phân.
Số 10 là độ dài của số cần mã hoá.
Cuối cùng là giá trị của số đó Mã hoá xâu :
counted string =: <integer><characters>
characters =: <character> | <character><characters>
Số ký tự có trong xâu được cho bởi số nguyên đứng ở đầu xâu. Ví dụ :
Value Encoded String
“abc”
“This is a long string”
+3abc
2+22this is a long string Số thực được mã hoá dạng :
real number =: <integer><integer>
Trong đó số nguyên đầu tiên được gọi là hệ số, biểu diễn số thực ban đầu dưới dạng số nguyên. Số nguyên tiếp theo biểu diễn số mũ trong hệ cở số 10 để số trước nhân với 10 với số mũ này ra số ban đầu. Ví dụ số 8.9 được chuyển thành số 89 và –1 sau đó được chuyển thành xâu.
PBS cung cấp sẵn một tập hợp các hàm để tiến hành mã hoá và giải mã với các dạng dữ liệu cơ sở, tập hợp các hàm này nằm trong thư viện đi kèm.
1. Đóng gói dữ liệu có cấu trúc
Ví dụ với một cấu trúc dữ liệu dạng danh sách móc nối như sau:
struct simple{ int n;
char str[30];
struct simple* next; }
Với cấu trúc như trên, khi muốn mã hóa một danh sách móc nối có kiểu như trên và có phần tử đầu tiên là firstnode thì ta làm như sau:
Đếm xem có bao nhiêu phần tử trong danh sách, mã hóa nó.
Duyệt từ firstnode, với mỗi phần tử thì tiến hành mã hóa các trường dữ liệu của nó chỉ trừ trường next:
Mã hóa số nguyên n Mã hóa xâu str
Với một mảng các đối tượng như sau: Object* arrayobject;
Việc mã hóa cũng được tiến hành tương tự như trên tức là đầu tiên tính số phần tử của mảng, mã hóa số đó ra gói tin, sau đó mã hóa từng phần tử của mảng với cách mà hóa tương tự như trên.
Đây cũng chính là cách mà PBS sử dụng để mã hóa những cấu trúc phức tạp mã ta sẽ thấy sau này.
Một số kết quả đã đạt được và định hướng phát triển
3. Một số kết quả trung tâm đã đạt được
K43-BKParaComp: Xây dựng môi trường phát triển ứng dụng song song với LAM MPI và PBS
K44-BKSupComp: Tích hợp khả năng chống lỗi cho MPICH và cải tiến cơ chế lập lịch của PBS
4. Định hướng phát triển
• Phát triển công cụ quản trị hệ thống
Phần 3 Tìm hiểu về chương trình Debugger
Debugger Interface
Khái niệm parallel Debugger
Debugger là cung cấp cho người sử dụng khả năng kiểm soát từ bên trong của một chương trình đang được thực hiện. Parallea debugger là công cụ debugger dành cho các chương trình song song
Xét một cách tổng quoát một chưong trình gồm có 3 phần là:
• Souce file: là file mã nguồn do người lập trình viết trên một ngông ngữ bậc cao nào đấy như C, Pascal…
• File chay: file sau khi đã được dịch từ souce ra mã máy, ở đây có sự liên kết giữa souce file và file chạy
• Các thư viện dùng chung: là các file đã được dịch của nhiều chương trình khác nhau và được chương trính chính của ta sử dụng .
Chương trình debugger mà chúng ta sẽ xây dựng có liên quan đến cả ba phần trên.
Khi một chương trình được thực thi thì bao gồm nhiều tiến trình cùng chạy đồng thời, mỗi tiến trình lại có thể bao gồm nhiều luồng, mỗi luồng có tập các thanh ghi và vùng nhớ stack riêng.
Một chương trình hoàn thiên bao gồm các tiến trình và các luồng có thể có thêm phần giao tiếp, giao tiếp với người sử dụng để lấy các thông tin đầu vào hoặc giao tiếp giứa các tiến trình với nhau, để kích hoạt cho chương trình hoạt động. Nói chung số lượng các tiến trình/luồng phụ thuộc vào nhiều yếu tố, như chất lượng của chương trình ban đầu, của chương trình sau khi dịch, cách chạy chương trính và số lượng các công việc cần giải quyết tuần tự. Vì vậy số lượng các tiến trình và luồng là không cố định đối với mỗi chương trình.
Debugger có thể sẽ rang buộc số lượng các tiến trình hay số luồng trong chương trình đích. Một threads-onlyDebugger là chưong trình gỡ rối chỉ có khả
này. Tưong tự như vậy, một processes_onlyDebugger không thể nhận ra các luồng bên trong một tiến trình. Thao tác này có thể áp dụng vào các chương trình gồm nhiều tiến trình nhưng mỗi tiến trình chỉ có một luồng. Chúng ta gọi một chương trình debugger có khả năng kiểm soát chương trình gồm nhiều tiến trình, mỗi tiến trình lại có nhiều luồng là bộ debugger đa mức, chúng ta sẽ bàn chủ yếu về những bộ debugger này.
Chúng ta chú ý rằng mọi chương trình parallel Debugger đều có thể sử dụng để debugger một chương trình tuần tự.
Cách thức hoạt động của chương trình Debugger
Debugger có ảnh hưởng đến chương trình nhưng không phải là một phần của chương trình. Chúng ta có thể hiểu debugger là việc chạy từng tiến trình một cách riêng rẽ. Debugger giao tiếp với chương trình thông qua execution-time interface
theo một nghĩa noà đó ta có thể coi debugger là một hệ điều hành đặc biệt.
Hình 2.1: Quan hệ giữa debugger và chương trình đích
Chúng ta đều biết rằng một chương trình bao gồm một tập hợp các trạng thái được thực hiện theo một thứ tự nhất định và khi debugger chương trình thì thứ tự của các trạng thái này không thay đổi. Tuy nhiên trong các chương trình song song, do có thể gồm nhiều tiến trình và nhiều luồng, sự can thiệp của debugger có thể thay đổi thời gian tương tác của các tiến trình này và sau đó quay trở lại tác động vào chương trình.
Debugger lấy file chạy làm đầu vào.Bởi vì debugger được hỗ trợ ở mức này nên mỗi một file chạy đều gắn với các thông tin debugger( debugging information). Trong tất cả các hệ thống đích yêu cầu các file chạy được chuẩn bị với một lựa chọn của compiler, như là “-g”.Các thông tin debugger có hai chức năng chính là:
• Cung cấp một cách để bộ debugger gửi các thông tin gỡ rối lên mức cao hơn cho người sử dụng.
• Đưa ra cách thức tiếp cân vào các thành phần bên trong của chương trình cho bộ debugger.
Các tiêu chuẩn trên không đưa ra các đặc điểm truy nhập khi file mã nguồn chưa được dịch và cung cấp đầy đủ các thông tin debugger.
Có ba cách để tiến hành debugger một chương trình. Cách thứ nhất là chương trình được chạy trong môi trường debugger, nghĩa là sau khi đã có bộ debugger.
Cách hai là bộ debugger kết hợp với một chương trình đã được thực hiện trong môi trường run-time. Trong trường hợp này nếu chương trình gồm nhiều tiến trình thì debugger có thể cần tương tác với môi trường run-time hoặc các thư viện đáp ứng được việc quản lý các tiến trình này.
Cách thứ ba là debugger được kết hợp với một chương trình song song mà kết thúc một cách không bình thường, một chương trình mà file chạy chương trình được tìm thấy và lưu trong một core file. Bởi vậy khi debugger không có bất cứ một tiến trình nào là thức sự gắn với chương trình đích cả và chỉ có thao tác debugger là có tác động đến core file debugging. Đặc biệt trong khi thực hiện bộ debugger có thể xác định vị trí của chương trình cũng như các giá trị các biến nhưng không thể thay đổi bất cứ điều gì ở trong core file.
Giao diện
Debugger có giao diên với người sử dụng , đây là nơi để chúng ta dùng để nhập các thông tin cần được kiểm soát trong quá trình debugger hoặc để đưa ra những thông tin về chương trình trong lúc chạy chương trình.
Debugger Output
Debugger các thông báo để trả lời về các thông tin mà chúng ta muốn biết khi tiến hành debugger chương trình. Một trong các thông tin này là thông báo xem các
thao tác có đợc thực hiên một cách thành công hay không , nếu có lỗi thì là lỗi gì và ở đâu. Ngoài ra cũng có thể đưa thêm các thông tin độ sâu chi tiết của chương trình đang debugger hay chính là chương trình đang chạy đến đâu( chúng ta thấy tượng tự khi chúng ta debugger một chương trình tuần tự cho chạy từng dòng lệnh.
Nói chung các thông báo lại cho người sử dụng là khác nhau với các dòng lệnh khác nhau.Chương tình HPD(High Performance Debugger) do nhóm HPDF(High Performance Debugger Forum) đưa ra phiên 1 có ba loại tham số điều khiển là
• ERR: tập cácc tham số này cho biết chương trình đã mắc lỗi
• WARN: tập các lời cành báo khi gặp các câu lệnh khó hiểu hay có khả năng mắc lỗi cao.
• ALL
Các tham số này được lưu trong biến trạng thái là VERBOSE.
Một loại biến điều khiển khác là ERROR_CHECKS cho phép người dùng điều khiển quá trình debugger bằng chách thay đổi giá trị các biến trong chương trình.
Hiệu ứng của sự song song trong quá trình debugger
1. Tên của các tiến trình và các luồng
Như chúng ta đã biết một chương trình song song luông bao gồm nhiều tiến trình chạy đồng thời và trong mỗi tiến trình lại có nhiều luồng vậy làm thế nào để quản lý được các luồng này trong quá trình debugger? Và người ta đã đưa ra giải pháp là gán một định danh cho mỗi tiến trình và mỗi luồng. Các định danh này có thể được tạo ra bởi chính bộ debugger hoặc có thể sử dụng một hệ thống nào đó để gán định danh cho các tiến trình. Nhưng chúng ta phải chú ý rằng mỗi định danh của một tiến trình là duy nhất trong quá trình debugger và định danh của mỗi luồng là duy nhất trong thời gian tồn tại của tiến trình.
Để minh hoạ chúng ta cùng xem xét một chương trình gồm có hai tiến trình, mỗi tiến trình có hai luồng, chúng ta sẽ có 4 luồng:
thread 0 of process 0 thread 1 of process 0 thread 0 of process 1 thread 1 of process 1
Chúng ta có mẫu định danh cho các luông như sau:
[process-identifier.thread-identifier]
Và ta có định danh của các luồng như sau: [0.0] - thread 0 of process 0
[0.1] - thread 1 of process 0 [1.0] - thread 0 of process 1 [1.1] - thread 1 of process 1 Chúng ta cũng có những quy ước:
*- xác định tất cả các định danh trong trong một vị trí xác định
: - tât cả các định danh trong phạm vi giơi hạn nào đó. Cụ thể giả sử chúng ta có:
0.*- các định danh của các luồng trong tiến trình 0.
0.*:4.*-các luồng trong các tiến trình từ không đến 4
1.2:1.5- các luồng trong phạm vi từ luồng 2 đến luồng 5 của tiến trình 1
2. Tập các tiến trình và luồng
Đây là khái niệm được mở rộng từ định nghĩa các tiến trình của lập trình tuần tự sao cho có thể phù hợp với môi trường lập trình song song. Việc coi tiến trình và luồng như nhau sẽ tạo điều kiện đểc ứng dụng các lênh debugger này vào cả chương trình gồm nhiều tiến trình cũng như các chương trình gồm nhiều luồng
Chúng ta định nghĩa tập các tiến trình và luồng là tập hợp gồm tất cả các luông trong tất cả các tiến trình của chương trình ban đầu. Một tập p/t( processes/threads) được giới hạn bên trong một dấu ngoặc vuông. Ví dụ :
[0.0,0.1,0.2] - the first 3 luồng trong tiến 0 [0.*] - tất cả các luồng trong tiến trình 0 [1.1, 2.1] - luồng 1 trong tiến trình 1 và 2 [1:2.1] - luồng 1 trong tiến trình 1 và 2.
Trong tập p/t nếu tồn tại hai giá trị bằng nhau sẽ sinh ra lời cảnh báo nhưng không ảnh hưởng gì đến quá trình debugger chương trình.
Không giống như khi debugger một chương trình tuần tự, khi mà mỗi lệnh chỉ sử dụng cho một luồng duy nhất, khi debugger một chương trình song song thì có thể có nhiều luồng điều khiển riêng biệt và đồng thời cũng có nhiều vị trí khác nhau trao đổi thông tin với chương trình. Để hạn chế bớt sự phức tạp của một lệnh debugger thì khái niêm tập đích đã ra đời, điều này giới hạn một lệnh được áp dụng cho một, nhiều hay tất cả các luồng điều khiển.
Tập đích có thể ảnh hưởng đến tất cả các lệnh debugger vì vậy bộ debugger cần phải có những quy tăc nghiêm ngặt để xác định tập đích.
3. Tập tên
Debugger tạo ra và lưu giữ các tập chứa mọi luồng, các tập này được tham chiếu bởi tên của tập. Mỗi tập chứa một loại luồng khác nhau. Trong HDP phiên bản 1 có 5 loại tập như vậy là:
• all: tập này chứa mọi luồng của chương trình
• running: chứa các luông đang ở trạng thái chạy.
• stopped: chứa mọi luồng ở trạng thái dừng
• runnable: chứa các luồng ở trạng thái dừng hoặc ở trạng thái runnable
• held: các luồng ở trạng thái dừng hoặc held
• exec: các luồng được đặt tên dạng executable
Các tập này có thể thay đổi trong quá trình debugger chương trình.
Trên đây là những lý thuyết ban đầu về xây dựng chương trình debugger cho một chương trình song song, tiếp theo chúng ta sẽ cùng tìm hiểu về một chương trình cụ thể đó là phiên bản HPD Version 1 do nhóm HPDF làm ra.
High Performance Debugger Version 1
1. Giới thiệu về nhóm HPDF
HPDF-High Performance Debugger Forum, là phòng thí nghiệm vừa tiến hành nghiên cứu đồng thời cũng phát triển các chương trình debugger trong môi trường
lập trình song song. Nhóm được thành lập năm 1997 với mục đích là đưa ra một công cụ debugger chuẩn cho hệ thống tính toán song song(High Performance Computing-HPC)
Mục tiêu của nhóm là xây dựng công cụ debugger chuẩn cho cả hệ thống chia sẻ bộ nhớ và hệ thống bộ nhớ phân tán