Mô hình OSI tổ chức giao thức truyền thông thành 7 tầng, mỗi tầng giải quyết một phần hẹp của tiến trình truyền thông, chia tiến trình truyền thông thành nhiều tầng và trong mỗi tầng có thể có các giao thức (Protocol) thực hiện các nhu cầu truyền thông cụ thể.

Mô hình OSI gồm 7 tầng như hình dưới.

Quá trình một gói tin được gửi từ máy A sang máy B qua mạng diễn ra như sau:

Tại máy A (máy gửi), dữ liệu do ứng dụng tạo ra sẽ lần lượt được đóng gói (encapsulation) khi đi từ tầng 7 (Application Layer) xuống tầng 1 (Physical Layer).
Mỗi tầng trong mô hình mạng sẽ thêm vào dữ liệu của tầng trên thông tin điều khiển tương ứng (header) để phục vụ cho việc định tuyến, kiểm soát kết nối và truyền dữ liệu qua mạng.

Sau khi xuống đến tầng vật lý, dữ liệu được chuyển thành các bit 0/1 và truyền đi trên môi trường truyền dẫn (cáp mạng, sóng vô tuyến, v.v.).

Tại máy B (máy nhận), tín hiệu nhận được sẽ được chuyển ngược từ dạng bit thành dữ liệu và lần lượt trải qua quá trình giải đóng gói (decapsulation) từ tầng 1 lên tầng 7.
Mỗi tầng sẽ bóc bỏ phần header tương ứng của mình, xử lý thông tin điều khiển, rồi chuyển dữ liệu còn lại lên tầng trên cho đến khi dữ liệu ban đầu được chuyển tới ứng dụng ở tầng ứng dụng.

1. Tầng 1 – Physical Layer (Tầng vật lý)

Chức năng

• Truyền bit 0/1 dưới dạng tín hiệu vật lý

• Quy định điện áp, sóng, tốc độ truyền

• Chuẩn hóa cáp, đầu nối, tần số

Thành phần liên quan

• Môi trường truyền: cáp mạng, cáp quang, sóng Wi-Fi

• Thiết bị: Hub, Repeater

• Chuẩn vật lý: RJ45, tốc độ 100Mbps, 1Gbps…

2. Tầng 2 – Data Link Layer (Tầng liên kết dữ liệu)

Chức năng

• Truyền frame trong cùng một mạng vật lý

• Địa chỉ hóa bằng MAC

• Phát hiện lỗi (CRC/FCS)

• Điều khiển truy cập đường truyền

Thành phần liên quan

• Giao thức: Ethernet, Wi-Fi (802.11)

• Thiết bị: Switch, NIC (card mạng)

• Địa chỉ: MAC Address

• Frame, FCS (CRC)

3. Tầng 3 – Network Layer (Tầng mạng)

Chức năng

• Định tuyến gói tin giữa các mạng khác nhau

• Xác định địa chỉ logic (IP)

• Chọn đường đi cho gói tin

Thành phần liên quan

• Giao thức: IP, ICMP

• Thiết bị: Router

• Địa chỉ: IPv4, IPv6

• Bảng định tuyến (Routing Table)

4. Tầng 4 – Transport Layer (Tầng giao vận)

Chức năng

• Truyền dữ liệu giữa 2 tiến trình (process-to-process)

• Chia nhỏ gói tin/ ghép gói tin

• Đảm bảo tin cậy, kiểm soát luồng, kiểm soát lỗi

• Định danh ứng dụng bằng port

Thành phần liên quan

• Giao thức: TCP, UDP

• Khái niệm: Port, Socket

• Thành phần OS: TCP/IP stack trong kernel

5. Tầng 5 – Session Layer (Tầng phiên)

Chức năng

• Thiết lập, duy trì và kết thúc phiên làm việc

• Quản lý trạng thái kết nối (session)

• Đồng bộ phiên, khôi phục khi gián đoạn

Thành phần liên quan

• Session trong ứng dụng web

• RPC session

• Session ID, Cookie

6. Tầng 6 – Presentation Layer (Tầng trình bày)

Chức năng

• Chuyển đổi định dạng dữ liệu

• Mã hóa / giải mã

• Nén / giải nén dữ liệu

Thành phần liên quan

• Chuẩn mã hóa: TLS/SSL, Base64

• Định dạng dữ liệu: JSON, XML, UTF-8

• Thư viện mã hóa / encode trong ứng dụng

7. Tầng 7 – Application Layer (Tầng ứng dụng)

Chức năng

• Cung cấp giao diện cho ứng dụng người dùng giao tiếp với mạng

• Thực hiện các dịch vụ mạng cấp cao: gửi mail, duyệt web, truyền file, gọi API…

Thành phần liên quan

• Giao thức: HTTP/HTTPS, FTP, SMTP, POP3, IMAP, DNS

• Ứng dụng: Web browser, Email client, API client

• Dịch vụ: Web server, Mail server

Lưu ý: Mô hình OSI chủ yếu dùng để học tập và phân tích hệ thống.
Trong triển khai thực tế, Internet sử dụng TCP/IP stack, trong đó các chức năng tầng 5 và 6 của OSI thường được gộp vào tầng ứng dụng.

Phân tích gói tin bằng phần mềm Wireshark

Hình minh họa cho thấy một gói tin HTTP thực tế được bắt bằng Wireshark.
Gói tin bao gồm đầy đủ các tầng giao thức trong TCP/IP stack:

Ethernet (tầng 2) → IP (tầng 3) → TCP (tầng 4) → HTTP (tầng 7).

Tầng 2 – Data Link (Ethernet II)

Ethernet II, Src: TPLink_77:23:4d (f0:09:0d:77:23:4d) Dst: LiteonTechno_6e:3e:e3 (14:b5:cd:6e:3e:e3)

• Địa chỉ MAC nguồn / MAC đích

• Frame Ethernet (giao thức Ethernet)

Tầng 3 – Network (IP)

Internet Protocol Version 4, Src: 23.203.133.184, Dst: 192.168.0.49

• Địa chỉ IP nguồn / IP đích

• Giao thức IP

Tầng 4 – Transport (TCP)

Transmission Control Protocol, Src Port: 80, Dst Port: 54803, Seq, Ack, Len

• TCP

• Port nguồn / đích

• Sequence, Acknowledgement

Tầng 7 – Application (HTTP)

Hypertext Transfer Protocol Line-based text data: text/plain

• HTTP/1.1

• Header + body của gói tin

The End.

Địa chỉ vật lý là địa chỉ thực trên RAM, là địa chỉ mà CPU cuối cùng sử dụng để truy cập bộ nhớ, thông qua khối quản lý bộ nhớ (MMU).

Địa chỉ logic là địa chỉ được gán cho các lệnh và dữ liệu khi chương trình chạy. CPU nhìn thấy và sử dụng các địa chỉ logic này để trỏ đến các phần khác nhau của lệnh và dữ liệu. Vùng không gian địa chỉ này gọi là không gian nhớ logic.

Như chúng ta đã biết mỗi tiến trình có không gian địa chỉ riêng như code/text, data, bss, heap, stack. Những địa chỉ này nằm trên không gian nhớ logic.

Khi chương trình chạy, địa chỉ logic cần được biến đổi thành địa chỉ vật lý nhờ một module phần cứng gọi là khối quản lý bộ nhớ (Memory Management Unit - MMU).

Như vậy để dễ quản lý và lập trình, địa chỉ logic là liên tục nhưng khi ánh xạ sang địa chỉ vật lý các địa chỉ này có thể là các địa chỉ rải rác và không liền mạch.

2. Phân trang (paging)

Bộ nhớ vật lý được chia thành các khối nhỏ có kích thước cố định bằng nhau gọi là khung trang (page frame). Trên hệ điều hành windows, thông thường mỗi khung trang có kích thước 4KB.

Để xem kích thước này trên windows chúng ta có thể xem qua phần mềm RamMap, ở tab Physical Pages.

Đơn vị nhỏ nhất của bộ nhớ RAM là 1 byte. 4KB (0x1000) là kích thước một trang (page) / khung trang (page frame).

Không gian địa chỉ logic của tiến trình cũng được chia thành những khối có địa chỉ liền nhau gọi là trang (page) có kích thước bằng với kích thước của khung trang.

Mỗi tiến trình sẽ được cấp phát các khung trang trong bộ nhớ vật lý (RAM) để chứa các trang nhớ của mình. Địa chỉ của các khung trang này có thể nằm rải rác không liên tục trong RAM.

Vì mỗi tiến trình được cấp phát nhiều khung có kích thước nhỏ nằm rải rác trên bộ nhớ vật lý, nhờ vậy giảm đáng kể tình trạng phân mảnh ở trong RAM.

3. Ánh xạ địa chỉ

Để ánh xạ địa chỉ logic thành địa chỉ vật lý, mỗi tiến trình có một bảng gọi là bảng trang (page table), mỗi ô của bảng tương ứng với một trang và chứa số hiệu của khung trang trong bộ nhớ vật lý.

Ở ví dụ trên tiến trình A được cấp phát 2 trang ảo là 0 và 1. Được ánh xạ qua page table tương ứng tới 2 khung trang A0 và A1 trong bộ nhớ vật lý.

Tiến trình B được cấp phát 3 trang ảo là 0, 1 và 2. Được ánh xạ qua page table tương ứng tới 3 khung trang B0, B1 và B2 trong bộ nhớ vật lý.

Địa chỉ vật lý được CPU truy cập sẽ được tính theo công thức

Page Frame Number là chỉ số của khung trang trong bộ nhớ vật lý.

Khi phần mềm đưa cho CPU một địa chỉ ảo, cách CPU tìm ra địa chỉ vật lý được diễn ra như sau.

Đầu tiên CPU sẽ căn cứ vào địa chỉ này để tính ra địa chỉ này tương ứng với số hiệu trang ảo (Virtual Page Number) là bao nhiêu và tính từ đầu trang ảo thì Offset là bao nhiêu.

CPU tra bảng trang để tìm ra số hiệu khung trang vật lý (Page Frame Number - PFN) tương ứng.

Sau khi có hai thông số này, CPU sử dụng công thức trên để tra ra địa chỉ vật lý.

Trên thực tế để tăng tốc quá trình truy cập địa chỉ, CPU sử dụng bộ nhớ cache TLB là bộ nhớ cache phần cứng dùng để lưu ánh xạ từ Virtual Page Number sang Page Frame Number. CPU sẽ tra TLB trước, nếu TLB miss mới truy cập page table trong RAM để lấy PFN.

Sau khi có địa chỉ vật lý, CPU tiếp tục truy cập cache dữ liệu L1/L2/L3 trước khi truy cập xuống RAM.

4. Lỗi trang (Page Fault) và Demand Paging

Lỗi trang (Page Fault) là một sự kiện xảy ra khi CPU không thể hoàn tất việc ánh xạ từ địa chỉ ảo sang địa chỉ vật lý do chưa có khung trang vật lý hợp lệ trong RAM, hoặc do vi phạm quyền truy cập bộ nhớ.

Page Fault xảy ra khi

• CPU truy cập một địa chỉ ảo

• Trang tương ứng chưa có trong RAM, hoặc

• Trang tồn tại nhưng không được phép truy cập (vi phạm quyền read/write/execute)

• Bảng trang (page table) không có ánh xạ hợp lệ cho trang đó

Demand Paging là một chính sách quản lý bộ nhớ mà hệ điều hành triển khai dựa trên cơ chế Page Fault.
Theo chính sách này, hệ điều hành không nạp toàn bộ chương trình vào RAM ngay từ đầu nhằm tránh lãng phí bộ nhớ, thay vào đó, các trang ảo chỉ được nạp vào RAM khi chương trình thực sự truy cập đến chúng.

Khi chương trình truy cập một trang lần đầu tiên, do trang đó chưa được cấp khung trang vật lý, nên Page Fault xảy ra. Lúc này, hệ điều hành sẽ:

• Cấp phát một Page Frame vật lý mới, hoặc

• Đọc nội dung trang từ disk (pagefile hoặc file backing) vào RAM

Sau đó, hệ điều hành cập nhật bảng trang và cho phép CPU thực thi lại lệnh gây ra Page Fault.

Việc sử dụng cơ chế Demand Paging giúp tránh lãng phí bộ nhớ vật lý, đồng thời cho phép hệ điều hành chạy song song nhiều chương trình hơn trên cùng một hệ thống.

Cơ chế Demand Paging và Page Fault được ứng dụng trực tiếp trong các API ánh xạ bộ nhớ như mmap (trên Linux/Unix) hoặc memory-mapped file trên Windows.

Cơ chế này cho phép giải quyết các bài toán xử lý file dữ liệu lớn trong khi vẫn tiết kiệm RAM, nhờ chỉ nạp vào bộ nhớ những phần dữ liệu thực sự được truy cập. Chủ đề này sẽ được trình bày chi tiết hơn trong một bài viết riêng về lập trình ánh xạ bộ nhớ.

The End.

1. Cách thức hoạt động của semaphore

Semaphore là một tập hợp các giấy phép (permits).

Để truy cập tài nguyên thi luồng phải yêu cầu một giấy phép. Nếu còn phép thì semaphore sẽ cho luồng đi tiếp và giảm số lượng giấy phép đi 1.

Nếu hết giấy phép thì luồng sẽ phải chờ cho đến khi có môt luồng khác trả lại giấy phép.

Sau khi luồng dùng xong sẽ trả lại giấy phép, khi đó số lượng giấy phép của semaphore sẽ tăng lên 1.

Một luồng sẽ thao tác với semaphore ở 2 trạng thái dưới:

• Wait: luồng kiểm tra semaphre, nếu còn giấy phép thì giảm giá số giá trị xuống 1, nếu không còn giấy phép thì đưa thread vào wait queue (trạng thái ngủ (sleep) không tiêu tốn CPU)

• Signal: luồng xử lý xong nếu có luồng đang wait thì đánh thức luồng đó, nếu không có luồng nào đang wait ở trong wait queue thì tăng semaphore lên 1.

2. Các loại semaphore

Binary Semaphore

Binary semaphore là semaphore chỉ có giá trị {0, 1} và chủ yếu được sử dụng để đồng bộ luồng (synchronization).

Chúng ta xem xét bài toán dùng binary semaphore để đồng bộ giữa ngắt của UART và task xử lý dữ liệu nhận trong hệ điều hành thời gian thực RTOS. Ban đầu, semaphore có giá trị khởi tạo là 0, Task này sẽ wait semaphore vô thời hạn trong vòng lặp. UART nhận dữ liệu xong sẽ phát sinh một ngắt nhận. Ngắt này sẽ phát tín hiệu signal cho task nhận dữ liệu.

Nhờ đó, task xử lý dữ liệu chỉ được đánh thức khi có ngắt nhận từ UART, sau khi xử lý xong task lại tiếp tục gọi wait và quay lại trạng thái sleep (blocked/waiting) để không gây tiêu tốn CPU trong thời gian chờ.

Counting Semaphore

Sử dụng khi có một tập hợp các tài nguyên hữu hạn.

Ví dụ về counting semaphore như sau:

Giả sử chúng ta có 2 phòng tắm (tài nguyên) khi đó semaphore ban đầu bằng 2.

Khi có người thứ nhất vào phòng, semaphore giảm xuống 1.

Khi có người thứ hai vào phòng, semaphore giảm xuống 0.

Khi người thứ 2 muốn vào phòng phải chờ cho 1 trong 2 người ra khỏi phòng mới được vào.

Như vậy counting semaphore giống như người điều tiết giao thông, đảm bảo không có quá nhiều luồng cùng vào một khu vực gây nghẽn hệ thống (concurrency limit).

Khi các luồng đã vượt qua cổng và vào được bên trong bằng giấy phép được cấp bởi semaphore nếu cùng tác động lên 1 biến, cấu trúc dữ liệu hay tài nguyên dùng chung thì semaphore không còn bảo vệ được nữa. Khi đó chúng ta cần dùng khóa Mutex hoặc các cơ chế tương đương để đảm bảo không gây ra Race Condition làm sai lệnh dữ liệu.

3. Ví dụ triển khai semaphore trong C++

Binary semaphore chủ yếu được ứng dụng trong lập trình nhúng và hệ thống thời gian thực (RTOS), trong phạm vi lập trình ứng dụng ở tầng user space thì counting semaphore được sử dụng phổ biến hơn để giới hạn mức độ song song nhiều luồng.

C++ 20 trở đi đã cung cấp counting_semaphore trong thư viện tiêu chuẩn STL.

Chú ý: để biên dịch trên vscode thì cần thêm cờ biên dịch “-std=c++20” và cấu hình biên dịch là c++20 trong cấu hình json c/c++ (nhấn tổ hợp phím Ctrl + Shift + P, sau đó chọn C/C++ Edit Configulations (JSON), cấu hình cppStandard là “c++20“).

{
    "configurations": [
        {
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "windowsSdkVersion": "10.0.26100.0",
            "compilerPath": "cl.exe",
            "cStandard": "c17",
            "cppStandard": "c++20",
            "intelliSenseMode": "windows-msvc-x64"
        }
    ],
    "version": 4
}

#include <semaphore>            // C++ 20
#include <mutex>
#include <thread>
#include <vector>
#include <iostream>
#include <string>
#include <atomic>

constexpr int MAX_RESOURCE  =   2;
constexpr int MAX_THREAD    =   4;

// Khởi tạo semaphore với giá trị ban đầu là 2
std::counting_semaphore<MAX_RESOURCE> sem(MAX_RESOURCE);

// Khai báo biến đếm mô phỏng số permit của semaphore
// Atomic là thao tác không thể chia nhỏ, đảm bảo không xảy ra race condition trong đa luồng, và được hỗ trợ bởi phần cứng CPU
// Lưu ý inside chỉ dùng để quan sát demo, không phải giá trị nội bộ của semaphore.
std::atomic<int> inside{0};

// Định nghĩa hàm safe log để in tuần tự ra console mà không bị dính chữ do tranh chấp
std::mutex log_mutex;
void safe_log(const std::string& msg) {
    std::lock_guard<std::mutex> lock(log_mutex);
    std::cout << msg << std::endl;
}

// Định nghĩa hàm xử lý cho các worker thread
void worker(int id) {
    std::string msg;
    msg = "Worker " + std::to_string(id) + " is waiting ...";
    safe_log(msg);

    // wait (lấy permit, nếu không có sẽ vào trạng thái blocked/wait không tiêu tốn CPU)
    sem.acquire();

    // Lấy permit thành công
    int current = ++inside;

    // do something
    msg = "Worker " + std::to_string(id) + " acquired resource" + "| inside: " + std::to_string(current);
    safe_log(msg);
    std::this_thread::sleep_for(std::chrono::seconds(1));  // sleep 1 giây

    current = --inside;
    msg = "Worker " + std::to_string(id) + " releasing resource" + "| inside: " + std::to_string(current);
    safe_log(msg);

    // signal (trả permit, đánh thức 1 thread đang wait nếu có)
    sem.release();
}

int main() {
    // định nghĩa vector để lưu handle của các thread
    std::vector<std::thread> threads;

    // khởi tạo các thread và nạp các handle của thread vào vector
    // lưu ý không dùng push_back trong trường hợp này vì handle của thread là đối tượng không thể sao chép
    for (int i = 0; i < MAX_THREAD; i++)
    {
        threads.emplace_back(worker, i);
    }

    // chờ cho các thread hoàn thành
    for(auto& t: threads) {
        t.join();
    }

    return 0;
}

Ở ví dụ trên, có 4 luồng chạy song song và có chia sẻ 2 nguồn tài nguyên.
Từ kết quả chúng ta có thể thấy tại một thời điểm chỉ có tối đa 2 luồng được sử dụng tài nguyên, điều này thể hiện ở biến inside.

The End.

Mutex là chìa khóa để bảo vệ tài nguyên chung, tại một thời điểm chỉ cho phép một luồng truy cập. Nếu coi Tài nguyên chung là một cái phòng có một cửa thì Mutex chính là cái chì khóa phòng. Luồng nào lấy được chìa khóa và đi vào phòng thì các luồng còn lại phải chờ ở ngoài. Chỉ khi luồng đang giữ chìa khóa mở cửa đi ra thì luồng khác mới có thể vào.

Chúng ta cần phân biệt kernel-space mutex (trên Windows được goi bằng API CreateMutex) và user-space mutex (C++ với thư viện std::mutex, CRITICAL_SECTION của windows).

Kernel-space mutex là một Kernel object có phạm vi toàn hệ thống (system-wide) được dùng để đồng bộ các tiến trình trong hệ điều hành. Mỗi khi mutex này lock/unlock, CPU phải thực hiện mode switch để chuyển từ user-mode sang kernel-mode, do đó chi phí để tạo mutex ở mức kernel là lớn.

User-space mutex có cấu trúc và chi phí triển khai nhẹ hơn phù hợp để đồng bộ các luồng trong cùng một tiến trình. Khi gọi loại mutex này nếu như không xảy ra tranh chấp thì sẽ không cần gọi vào kernel mode. Do đó chi phí trung bình nhỏ hơn nhiều.

Ở phạm vi lập trình ứng dụng, đồng bộ các luồng của cùng một tiến trình ở bài viết này, chúng ta sẽ nói về user-space mutex.

Cùng xem xét một ví dụ sau viết bằng c++ trên windows, sử dụng win32 api để tạo thread.

#include <process.h>
#include <windows.h>
#include <iostream>

// Hàm xử lý của thread 1
unsigned __stdcall t1_worker(void* args) {
    while (true)
    {
        std::cout << "Thread " << "1 " << "is running ... \n";
        Sleep(1000);
    }
    return 0;
}

// Hàm xử lý của thread 2
unsigned __stdcall t2_worker(void* args) {
    while (true)
    {
        std::cout << "Thread " << "2 " << "is running ... \n";
        Sleep(1000);
    }
    return 0; 
}

int main() {
    // Khởi tạo thread 1
    uintptr_t t1_Handle = _beginthreadex(NULL, 0, t1_worker, NULL, 0, 0);

    // Khởi tạo thread 2
    uintptr_t t2_Handle = _beginthreadex(NULL, 0, t2_worker, NULL, 0, 0);

    // Chờ cho hai thread kết thúc
    // Thực tế 2 thread sẽ chạy mãi trong vòng lặp while(true)
    WaitForSingleObject((HANDLE)t1_Handle, INFINITE);
    WaitForSingleObject((HANDLE)t2_Handle, INFINITE);

    // Đóng các thread handler
    CloseHandle((HANDLE)t1_Handle);
    CloseHandle((HANDLE)t2_Handle);

    return 0;
}

Kết quả: ở lần chạy thứ 6 của vòng lặp while, khi thread 2 đang sử dụng đối tượng std::cout để ghi ra console chữ “Thread 2“ thì window schedule (bộ lập lịch) đã dừng thread hiện tại và chuyển CPU sang thread 1.

Std:cout là đối tượng tài nguyên dùng chung (shared resource), ở ví dụ trên đã có hiện tượng race condition xảy ra, hai thread tranh nhau sử dụng để in ra màn hình console.

Để không xảy ra vấn đề này chúng ta sử dụng Mutex để đảm bảo mỗi thread ghi chuỗi hoàn tất thì các thread khác mới được quyền sử dụng đối tượng std::cout.

Trong C++ sử dụng thư viện std::mutex để triển khai như sau.

#include <process.h>
#include <windows.h>
#include <iostream>
#include <mutex>

// Khai báo đối tượng mutex toàn cục
std::mutex g_Mutex;

// Hàm xử lý của thread 1
unsigned __stdcall t1_worker(void* args) {
    while (true)
    {
        {
            // Sử dụng lock_guard để tự động mở khóa
            std::lock_guard<std::mutex> lock(g_Mutex);
            std::cout << "Thread " << "1 " << "is running ... \n";
        }
        Sleep(1000);
    }
    return 0;
}

// Hàm xử lý của thread 2
unsigned __stdcall t2_worker(void* args) {
    while (true)
    {
        {
            // Sử dụng lock_guard để tự động mở khóa
            std::lock_guard<std::mutex> lock(g_Mutex);
            std::cout << "Thread " << "2 " << "is running ... \n";
        }
        Sleep(1000);
    }
    return 0;
}

int main() {
    // Khởi tạo thread 1
    uintptr_t t1_Handle = _beginthreadex(NULL, 0, t1_worker, NULL, 0, 0);
    if(t1_Handle == 0) {
        std::cout << "Lỗi khởi tạo thread 1\n";
        return 1;
    }

    // Khởi tạo thread 2
    uintptr_t t2_Handle = _beginthreadex(NULL, 0, t2_worker, NULL, 0, 0);
    if(t2_Handle == 0) {
        std::cout << "Lỗi khởi tạo thread 2\n";
        return 1;
    }

    // Chờ cho hai thread kết thúc
    // Thực tế 2 thread sẽ chạy mãi trong vòng lặp while(true)
    WaitForSingleObject((HANDLE)t1_Handle, INFINITE);
    WaitForSingleObject((HANDLE)t2_Handle, INFINITE);

    // Đóng các thread handler
    CloseHandle((HANDLE)t1_Handle);
    CloseHandle((HANDLE)t2_Handle);

    return 0;
}

Kết quả đã không xảy ra tình trạng các chữ bị in chồng lấn như trước.

Lưu ý:

Mặc dù Mutex giúp đảm bảo tính đúng đắn của dữ liệu hoặc tranh chấp về tài nguyên dùng chung như std::cout chúng ta vừa khảo sát, nhưng nếu tranh chấp xảy ra nhiều, việc thực hiện Lock/Unlock quá thường xuyên sẽ làm thread bị block và phát sinh Context Switch gây chi phí lớn. Do đó, cần xem xét kỹ tần suất sử dụng và giữ thời gian chiếm giữ khóa (Lock time) ngắn nhất có thể để tránh làm giảm hiệu năng tổng thể của ứng dụng đa luồng.

Ở bài tiếp theo, chúng ta sẽ tìm hiểu Semaphore và cách sử dụng semaphore để đồng bộ hóa trong lập trình đa luồng.

The End.

1.　Race condition

Race condition xảy ra khi kết quả của một chương trình phụ thuộc vào thứ tự thực thi không thể đoán trước của các luồng (Timing).

Giả sử 2 luồng cùng truy cập vào biến bất kỳ, sẽ có 3 trường hợp xảy ra như sau

- Hai luồng cùng đọc đồng thời (R-R): trường hợp này an toàn, không có nguy cơ gây ra lỗi dữ liệu.

- Một luồng đọc, một luồng ghi (R-W, W-R): trường hợp này phân thành hai trường hợp nhỏ hơn

• Đọc trước ghi sau (R-W): nguy cơ luồng đọc dữ liệu không lấy được dữ liệu mới nhất. Giả sử luồng đọc lấy được giá trị X = 10, ngay sau đó luồng ghi cập nhật X = 20. Luồng đọc vẫn tiếp tục xử lý với giá trị X = 10 mà không biết giá trị đó đã hết hạn hoặc đã cũ.

• Ghi trước đọc sau (W-R): Luồng ghi đang cập nhật dữ liệu nhưng chưa hoàn chỉnh, thì luồng đọc lấy dữ liệu. Dữ liệu này không phải giá trị cũ cũng không phải giá trị mới (dữ liệu bẩn).

- Hai luồng ghi đồng thời (W-W): Khi hai luồng cùng ghi vào một giá trị, nguy cơ xảy ra tình trạng giá trị của một luồng bị ghi đè bởi luồng kia. Ví dụ biến toàn cục X = 10, hai luồng cùng tăng X lên 1. Mỗi phép tăng gồm ba bước: đọc X, cộng 1, rồi cập nhật giá trị cho X. Nếu hai luồng cùng đọc được X = 10 trước khi bất kỳ luồng nào kịp ghi kết quả, khi đó cả hai đều ghi giá trị 11. Kết quả cuối cùng X = 11 thay vì 12 như mong đợi. Một ví dụ khác, nếu như hai luồng cùng ghi vào một cấu trúc dữ liệu lớn, nếu không được đồng bộ có nguy cơ xảy ra tình trạng dữ liệu sau khi được ghi có một nửa mang giá trị của luồng thứ nhất và một nửa mang giá trị của luồng thứ 2.

Để đồng bộ các luồng truy cập dữ liệu đọc/ghi một cách an toàn, chúng ta có một vài cơ chế phổ biến đó là Critical Section, Mutex và Semaphore.

2. Critical Section (Vùng găng)

Critical Section là đoạn code mà tại đó có nguy cơ xảy ra race condition. Hệ điều hành Windows cung cấp cho chúng ta một đối tượng CRITICAL_SECTION chạy chủ yế ở user-mode để bảo vệ vùng găng ở trên, đảm bảo tại mỗi thời điểm chỉ có một luồng được phép truy cập vào tài nguyên chung.

Khi vùng găng đang được lock bởi một luồng khác thì luồng muốn vào sẽ chuyển sang chế độ Sleep đề chờ cho tới khi vùng găng được unlock.

Chúng ta cùng xem xét một ví dụ sau trên windows:

#include <Windows.h>
#include <stdio.h>

int x = 0;

// Hàm xử lý thread 1
DWORD WINAPI Worker_T1(LPVOID param) {
    for (size_t i = 0; i < 500000; i++)
    {
        x++;
    }
    return 0;
}

// Hàm xử lý thread 2
DWORD WINAPI Worker_T2(LPVOID param) {
    for (size_t i = 0; i < 500000; i++)
    {
        x++;
    }
    return 0;
}

int main() {
    // Khởi tạo thread t1
    HANDLE t1ThreadHandle = CreateThread(0, 0, Worker_T1, NULL, 0, NULL);
    if(!t1ThreadHandle) {
        printf("T1 thread create failed\n");
        return 1;
    }

    // Khởi tạo thread t2
    HANDLE t2ThreadHandle = CreateThread(0, 0, Worker_T2, NULL, 0, NULL);
    if(!t2ThreadHandle) {
        printf("T2 thread create failed\n");
        return 1;
    }

    // Main thread chờ cho 2 luồng thực hiện xong
    WaitForSingleObject(t1ThreadHandle, INFINITE);
    WaitForSingleObject(t2ThreadHandle, INFINITE);

    // Đóng các handle
    CloseHandle(t1ThreadHandle);
    CloseHandle(t2ThreadHandle);

    printf("Final x = %d\n", x);

    return 0;
}

Kết quả: chúng ta có thể thấy mỗi lần chạy chương trình lai cho ra một kết quả khác nhau. Không ra được kết quả như mong đợi (1.000.000).

Để không xảy ra vấn đề này chúng ta sử dụng đối tượng CRITICAL_SECTION do hệ điều hành windows cung cấp để bảo vệ vùng găng như sau:

#include <Windows.h>
#include <stdio.h>

int x = 0;

// Khai báo đối tượng CRITICAL_SECTION để đồng bộ
CRITICAL_SECTION g_cs;

// Hàm xử lý thread 1
DWORD WINAPI Worker_T1(LPVOID param) {
    for (size_t i = 0; i < 500000; i++) {
        // Khóa quyền truy cập biến x
        EnterCriticalSection(&g_cs);
        x++;
        LeaveCriticalSection(&g_cs);
    }
    return 0;
}

// Hàm xử lý thread 2
DWORD WINAPI Worker_T2(LPVOID param) {
    for (size_t i = 0; i < 500000; i++) {
        // Chờ cho đến khi được quyền truy cập vào biến x
        EnterCriticalSection(&g_cs);
        x++;
        LeaveCriticalSection(&g_cs);
    }
    return 0;
}

int main() {

    // Khởi tạo đối tượng CRITICAL_SECTION
    InitializeCriticalSection(&g_cs);

    // Khởi tạo thread t1
    HANDLE t1ThreadHandle = CreateThread(0, 0, Worker_T1, NULL, 0, NULL);
    if(!t1ThreadHandle) {
        printf("T1 thread create failed\n");
        return 1;
    }

    // Khởi tạo thread t2
    HANDLE t2ThreadHandle = CreateThread(0, 0, Worker_T2, NULL, 0, NULL);
    if(!t2ThreadHandle) {
        printf("T2 thread create failed\n");
        return 1;
    }

    // Main thread chờ cho 2 luồng thực hiện xong
    WaitForSingleObject(t1ThreadHandle, INFINITE);
    WaitForSingleObject(t2ThreadHandle, INFINITE);

    // Đóng các handle của luồng
    CloseHandle(t1ThreadHandle);
    CloseHandle(t2ThreadHandle);

    // Xóa đối tượng CRITICAL_SECTION
    DeleteCriticalSection(&g_cs);

    printf("Final x = %d\n", x);

    return 0;
}

Kết quả đã không xảy ra tình trạng sai lệch giá trị của biến x

Ở bài tiếp theo, chúng ta sẽ tìm hiểu về Mutex và cách sử dụng để đồng bộ hóa trong lập trình đa luồng.

The End.

Một tiến trình có thể chỉ có một luồng hoặc có nhiều luồng chạy song song để xử lý các công việc khác nhau.

Giả sử chúng ta có một bài toán như sau: tạo một phần mềm vừa tính toán xử lý dữ liệu rất lớn tốn thời gian (CPU-bound), vừa phải thực hiện truy vấn cơ sở dữ liệu để lấy thông tin (I/O-bound).

Trong những trường hợp như vậy có hai hướng tiếp cận.

Nếu như driver của Database không hỗ trợ API bất đồng bộ, ngoài luồng chính để điều phối chương trình, chúng ta cần thiết kế các luồng chạy song song, một luồng chuyên để tính toán xử lý dữ liệu và một luồng khác chuyên phục vụ truy vấn cơ sở dữ liệu.

Nếu như driver của Database hỗ trợ API bất đồng bộ thì luồng chính có thể gọi API bất đồng bộ, phần I/O sẽ được hệ thống hoặc thư viện xử lý ở tầng bên dưới (thread pool/ event loop), ứng dụng chỉ cần thêm luồng riêng cho tác vụ CPU-bound.

Trên Windows luồng có thể được tạo bằng API CreateThread, trong khi đó trên Linux sử dụng POSIX Threads để tạo và quản lý luồng.

Chúng ta cùng demo một chương trình tạo ra các luồng trên Windows và Linux.

Ví dụ đa luồng trên Linux:

#include <stdio.h>
#include <pthread.h>
#include <unistd.h>

// hàm xử lý cho luồng tính toán
void* Compute(void* args) {
    for (int i = 0; i < 10; i++)
    {
        printf("[Worker thread]::Compute step ... %d\n", i);
        sleep(1);
    }
    return NULL;
}

int main() {
    printf("[Main thread]::Start\n");

    // tạo luồng tính toán
    pthread_t computeThread;
    if(pthread_create(&computeThread, NULL, Compute, NULL) != 0)
    {
        printf("Thread create error\n");
        return 1;
    }

    // luồng chính vẫn đang chạy song song
    for (int i = 0; i < 10; i++)
    {
        printf("[Main thread]::Do other something ... %d\n", i);
        sleep(1);
    }

    // chờ luồng tính toán kết thúc
    pthread_join(computeThread, NULL);

    printf("[Main thread]::End\n");
    return 0;
}

Kết quả chúng ta có 1 luồng mới chạy song song với luồng chính như kết quả dưới đây.

Ví dụ đa luồng trên Windows sử dụng thư viện Win32 API:

#include <stdio.h>
#include <Windows.h>

int x = 0;

// Hàm xử lý cho worker thread
DWORD WINAPI Worker(LPVOID params) {
    for (int i = 0; i < 5; i++)
    {
        printf("Worker thread id = [%lu]: %d\n", GetCurrentThreadId(), i);

        // tăng x lên 1
        x = x + 1;

        Sleep(1000);
    }

    return 0;
}

int main() {
    // ở luồng chính tăng biến x lên 1
    x = x + 1;

    // Tạo hai luồng 
    HANDLE threads[2];
    for (int i = 0; i < 2; i++)
    {
        threads[i] = CreateThread(NULL, 0, Worker, NULL, 0, NULL);
        if(threads[i] == NULL) {
            printf("Create thread failed\n");
            return 1;
        }
    }

    // Chờ 2 luồng kết thúc xử lý
    WaitForMultipleObjects(2, threads, TRUE, INFINITE);
    CloseHandle(threads[0]);
    CloseHandle(threads[1]);

    // Kiểm tra giá trị biến x
    printf("x = %d\n", x);

    // Kết thúc luồng chính
    printf("Main thread finished\n");
    return 0;
}

Kết quả chúng ta có hai luồng chạy song song ngoài luồng chính.

Ở ví dụ trên, biến x trước khi kết thúc hàm main có giá trị là 11, chúng ta có thể thấy x đã được tăng lên 1 bở hàm main và tăng thêm 10 bởi 2 worker thread.

Các thread trên cùng một process chia sẻ chung một không gian địa chỉ (Heap, global, file handler) nhưng mỗi thread có Stack và Contex riêng (register, instruction pointer).

Trên Windows Các thông tin riêng của Tthread như Stack và Contex được Kernel lưu ở TCB (Thread Control Block) của mỗi thread, không nằm trong PCB (Process Control Block) của tiến trình.

Trên linux không phân biệt PCB hay TCB mà các thread đều được biểu diễn bằng struct task_struct, tiến trình là một nhóm các thread chia sẻ tài nguyên.

Lưu ý ở ví dụ trên, biến x là biến dùng chung và được đọc/ghi đồng thời bởi các thread. Để không phát sinh các vấn đề gây ra sai lệch dữ liệu (giá trị x có thể không đảm bảo là 11) chúng ta sẽ cần cơ chế đồng bộ để các thread có thể đọc/ghi an toàn.
Vấn đề này chúng ta sẽ làm rõ ở bài tiếp theo.

The End.

• Lưu ý: đây là tổ chức bộ nhớ của tiến trình bên trong bộ nhớ ảo, không phản ánh thực tế bên trong bộ nhớ chính (RAM), các địa chỉ này sẽ được đơn vị quản lý bộ nhớ (MMU - Memory Management Unit) ánh xạ lên địa chỉ thật ở trên RAM.

1. Code segment (Text segment)

Đây là phần mã lệnh (Code/Text) sau khi chương trình được biên dịch sang mã máy. Hay chính là các câu lệnh chỉ thị cho CPU thực hiện.

Cùng xem câu lệnh ở bên dưới:

int x = 10;
x = x + 1;

“x = x + 1“ khi được biên dịch sẽ sinh ra mã máy, và mã máy đó được lưu trong Code/Text segment.

Đặc điểm quan trọng của phần Code/Text:

• Đây là phần chỉ đọc (Read only) tránh cho chương trình tự sửa code

• Nạp từ file thực thi vào RAM khi tạo process

2. Data Segment

Data Segment là nơi lưu trữ các biến toàn cục (global) và biến tĩnh đã được khởi tạo khác 0.

Data bao gồm 2 vùng là .data và .rodata

.data là vùng chứa biến có thể thay đổi (Read/Write)

.rodata là vùng chứa các hằng số (Read only)

Chúng ta cùng xem xét một chương trình đơn giản như sau:

int a = 10;
int b;
int c = 0;
const char* d = "abc";

int main() {
    int e = 100;
    const char* f = "abc";
    static int g = 20;
    static int h;
    static int i = 0;
    static const char* j = "abc";
    return 0;
}

a là biến toàn cục có khởi tạo khác 0 → a nằm trong Data Segment (vùng .data).

b là biến toàn cục không có khởi tạo và c là biến toàn cục khởi tạo bằng 0 → b và c không nằm trong Data Segment. (b và c nằm trong vùng .bss)

d là biến toàn cục có khởi tạo khác 0 → d nằm trong Data Segment (vùng .data), “abc“ là hằng số nằm trong vùng .rodata của Data Segment.

các biến e và f là biến cục bộ (local) của hàm main() → e và f không nằm trong Data Segment. (Nằm trong stack của hàm main() bên trong vùng Stack).

g là biến static có khởi tạo khác 0 → g nằm trong vùng .data của Data Segment.

h và i là biến static chưa được khởi tạo hoặc khởi tạo bằng 0 → h và i không nằm trong Data Segment (h và i nằm trong vùng .bss)

j là biến static có khởi tạo khác 0 → j nằm trong vùng .data của Data Segment, “abc“ sẽ nằm trong vùng .rodata của Data Segment.

3. bss Segment

Bss là vùng bộ nhớ được hệ điều hành cấp phát khi khởi tạo process để lưu trữ các biến toàn cục (global) hoặc biến static chưa được khởi tạo hoặc khởi tạo bằng 0, mục đích là để giảm kích thước file thực thi.

4. Heap

Heap là vùng bộ nhớ được cấp phát động trong quá trình thực thi tiến trình, ví dụ thực hiện hàm malloc() trong ngôn ngữ c hoặc toán tử new trong các ngôn ngữ bậc cao.

Chúng ta cùng xem xét ví dụ sau:

#include <stdlib.h>

int main() {
    // Cấp phát một mảng có kích thước là 400 bytes
    int* p = malloc(100 * sizeof(int));
    if(!p) return 1;

    // Giải phóng vùng nhớ trên Heap sau khi sử dụng
    free(p);
    p = NULL;

    return 0;
}

p la biến cục bộ của hàm main() → p nằm ở trong stack của hàm main() trong vùng Stack.

Vùng nhớ có kích thước 100 * sizeof(int) (400 bytes) nằm trong vùng Heap.

Thông thường các biến cục bộ của hàm nằm trên stack của hàm sẽ được giải phóng theo phạm vi { } của hàm, nhưng khi cấp phát vùng nhớ trong vùng Heap để sử dụng, cần được giải phóng sau khi sử dụng, vì các vùng nhớ này không được tự giải phóng theo phạm vi của hàm.

5. Stack

Stack là vùng nhớ lưu các biến cục bộ, các tham số hàm và địa chỉ trả về của hàm.

Địa chỉ trả về của hàm là là địa chỉ của lệnh tiếp theo ngay sau lời gọi hàm.

Stack hoạt động theo nguyên lý LIFO (last in first out - vào sau ra trước)

Chúng ta cùng xem xét ví dụ sau:

int total(int a, int b) {
    return a + b;
}

int main() {
    int a = 2;
    int b = 3;
    int c = total(a, b);

    return 0;
}

Khi tiến trình được tạo, hàm main sẽ được cấp phát một vùng nhớ trong Stack (main stack frame), trong đó lưu các biến a, b, c và địa chỉ trả về của hàm main.

Khi hàm total được gọi, một stack frame mới cho total được tạo trong Stack (total stack frame), copy của các giá trị a và b và địa chỉ trả về của hàm total (địa chỉ của câu lệnh gán giá trị của total cho biến c trong hàm main) được đẩy vào total stack frame.

Sau khi hàm total thực hiện xong total stack frame sẽ được giải phóng khỏi Stack.

Sau khi gán giá trị của total cho biến c, hàm tiếp tục câu lệnh return 0, main stack frame sẽ được giải phóng khỏi Stack để chuẩn bị các câu lệnh kết thúc tiến trình.

Như vậy Stack hoạt động theo nguyên lý LIFO. Mỗi hàm được gọi sẽ tạo ra một stack frame mới và bị hủy khi hàm kết thúc.

Hiểu rõ tổ chức bộ nhớ của tiến trình giúp tránh lỗi memory, debug chính xác và viết chương trình hiệu quả hơn.

The End.

Tiến trình được tạo ra khi một chương trình được tải vào bộ nhớ để thực thi.

1. Các trạng thái của tiến trình

Trạng thái của tiến trình là cách hệ điều hành theo dõi quá trình hoạt động của tiến trình. Mỗi tiến trình luôn nằm trong một trạng thái cụ thể tại một thời điểm. Trạng thái tiến trình thay đổi khi chạy, chờ, hay bị tạm dừng.

a. New

Tiến trình được tạo mới nhưng chưa sẵn sàng để chạy (chưa vào hàng đợi Ready).

b. Ready

Tiến trình đang ở trong bộ nhớ chờ CPU chọn để chạy.

c. Running

Tiến trình đang được CPU thực thi lệnh.

d. Waiting/Blocked

Tiến trình chuyển sang trạng thái chờ hoặc blocked khi chờ xử lý sự kiên I/O ví dụ như đọc/ghi file đồng bộ. Khi đó việc đọc/ghi file được thực hiện bằng các hàm đọc file của hệ điều hành. Tiến trình sẽ rơi vào trạng thái blocked để chờ các tác vụ này hoàn thành mới tiếp tục.

Tiến trình ở trạng thái blocked sẽ không được chọn để chạy dù CPU rảnh.

e. Terminated/Exit

Tiến trình đã thực hiện xong chuyển sang trạng thái kết thúc.

2. Thông tin mô tả của tiến trình

Thông tin của tiến trình được lưu trong một cấu trúc dữ liệu là PCB (Process Control Block) gọi là khối quản lý tiến trình.

Trong mã nguồn của hệ điều hành Linux, thông tin của tiến trình (PCB) được lưu trong struct task_struct, định nghĩa trong file sched.h của mã nguồn.

Chúng ta hãy xem mã nguồn Linux phiên bản rút gọn của struct task_struct như sau:

struct task_struct {
    pid_t pid;             
    pid_t tgid;                   
    struct task_struct *real_parent;
    struct task_struct *parent;
    struct list_head children;
    struct list_head sibling;
    struct task_struct *group_leader;
    char comm[TASK_COMM_LEN];

    unsigned int __state; 

    int prio;
    int static_prio;
    int normal_prio;
    unsigned int rt_priority;
    struct sched_entity se;        
    struct sched_rt_entity rt;     
    struct sched_dl_entity dl;     
    const struct sched_class *sched_class;

    struct mm_struct *mm;          
    struct mm_struct *active_mm;   

    struct files_struct *files;    
    struct fs_struct *fs;          

    struct signal_struct *signal;
    struct sighand_struct __rcu *sighand;
    sigset_t blocked;
    struct sigpending pending;

    int on_cpu;                     
    int on_rq;                      
    u64 utime;                      
    u64 stime;                      
    u64 start_time;                 
    unsigned long nvcsw;            
    unsigned long nivcsw;           

    struct list_head tasks;         

    struct thread_struct thread;
};

a. Nhóm định danh và mối quan hệ của tiến trình, giúp Kernel biết tiến trình là ai và thuộc về đâu.

• pid (Process ID): Trong Linux, mỗi thread cũng được coi là một process, vì vậy mỗi thread có một pid riêng.

• tgid (Thread Group ID): mã số định danh duy nhất của tiến trình, Các thread thuộc cùng một tiến trình có chung tgid.

b. Nhóm trạng thái và lập lịch (State, Scheduling)

• __state: là trạng thái của tiến trình như RUNNING, BLOCKED …

• prio: mức độ ưu tiên của tiến trình, Kernel dùng để tính toán xem tiến trình có được ưu tiên chiếm CPU của các tiến trình khác hay không.

c. Nhóm quản lý bộ nhớ

• mm: con trỏ trỏ đến không gian bộ nhớ của tiến trình trong RAM (Code/Text, Data, bss, Heap, Stack)

d. Nhóm quản lý file và hệ thống tệp

• files: bảng mô tả file, lưu danh sách các file mà tiến trình đang mở

• fs: lưu thông tin về thư mục gốc (root) và thư mục hiện hành (curent working directory) của tiến trình

e. Nhóm thống kê tài nguyên

• utime/stime: thống kê thời gian tiến trình chạy ở chế độ User mode và Kernel mode

• start_time: thời điểm tiến trình được tạo

f. Liên kết tiến trình

• list_head tasks: kết nối tiến trình vào danh sách chứa toàn bộ tiến trình toàn hệ thống, giúp scheduler duyệt và quản lý toàn bộ tiến trình.

3. Xem thông tin của tiến trình đang chạy trong Linux

Trong linux, tiến trình đang chạy được lưu trong thư mục /proc.

Mỗi tiến trình có một thư mục con theo PID (process ID)

chúng ta có thể xem toàn bộ các tiến trình bằng câu lệnh:

cd /proc
ls

Mỗi thư mục 1, 110, 114 … là số PID tương ứng của một tiến trình.

Chúng ta có thể truy cập vào từng thư mục để xem cụ thể thông tin của một tiến trình cụ thể (ví dụ tiến trình có mã số PID là 110) như sau:

cd 110
cat status

• Name: là tên tiến trình

• State: là trạng thái hiện tại (Sleeping)

• Pid: 110

4. Chuyển đổi giữa các tiến trình

Trong quá trình thực hiện, CPU có thể chuyển từ thực hiện tiến trình hiện thời sang thực hiện tiến trình khác. Trong trường hợp như vậy hệ điều hành cần lưu thông tin của tiến trình đang chạy để có thể khôi phục và thực hiện lại tiến trình tự thời điểm bị tạm dừng.

Thông tin về tiến trình hiện thời được gọi là Context và việc chuyển đổi giữa các tiến trình là chuyển đổi ngữ cảnh - Context Switch.

Việc chuyển đổi tiến trình xảy ra trong các trường hợp sau:

• Khi có ngắt:

• khi tiến trình gọi lời gọi hệ thống

Ngắt: có thể sinh ra do các sự kiện bên ngoài (ngắt do Time Tick khi tiến trình đã chạy hết thời gian được phân bổ, ngắt vào ra dữ liệu của DMA, ngắt khi bấm phím trên bàn phím … ) hoặc ngắt do lỗi phát sinh bên trong tiến trình.

Lời gọi hệ thống: ví dụ khi tiến trình gọi các hàm đọc/ghi file của hệ điều hành.

Ngữ cảnh của tiến trình được lưu trong cấu trúc PCB được mô tả ở trên.

Trước khi xảy ra Context Switch để thực hiện tiến trình khác, các thông tin có thể thay đổi như nội dung các thanh ghi, trạng thái của CPU sẽ được lưu vào PCB.

Sau khi kết thúc ngắt các thông tin về các thanh ghi, trạng thái của CPU được nạp lại từ PCB và tiến trình có thể tiếp tục thực hiện lại từ vị trí trước khi bị ngắt.

Tóm lại, để có thể chuyển đổi giữa các tiến trình thì hệ thống cần thực hiện một số bước liên quan tới việc lưu và khôi phục ngữ cảnh của tiến trình.

The End.

1. Thanh ghi (nằm trong CPU) - Register

   Thanh ghi là bộ nhớ có dung lượng rất nhỏ nằm trực tiếp trong CPU và được quản lý trực tiếp bởi CPU.

   Đây là nơi lưu giữ:

   Toán hạng đang được xử lý.

   Kết quả trung gian.

   Địa chỉ bộ nhớ, trạng thái CPU, lệnh đang được thực thi.

   Thanh ghi có tốc độ truy xuất nhanh nhất trong bộ nhớ của CPU.

2. Bộ nhớ đệm (nằm giữa CPU và RAM) - Cache

   Đây là bộ nhớ tạm thời tốc độ cao dùng để lưu dữ liệu và lệnh truy cập thường xuyên.

   Bộ nhớ Cache nằm giữa CPU và Bộ nhớ chính (RAM).

   Khi CPU cần dữ liệu, sẽ truy cập Cache trước, nếu có (Cache hit) sẽ dùng ngay, nếu không có (Cache miss) sẽ truy cập RAM để lấy dữ liệu, sau đó dữ liệu đó được copy vào Cache để dùng cho lần sau.

   Kích thước của Cache thông thường từ vài KB đến 4 MB tùy thuộc loại Cache L1, L2 hay L3.

3. Bộ nhớ chính - RAM

   Đây là bộ nhớ lưu giữ chương trình và dữ liệu đang được thực thi.

   RAM nằm ngoài CPU và được kết nối với CPU thông qua bus bộ nhớ và có tốc độ chậm hơn Cache.

   Khi chương trình chạy, hệ điều hành nạp chương trình và dữ liệu từ Disk vào RAM, CPU không truy cập trực tiếp vào Disk mà làm việc trực tiếp với dữ liệu ở trong RAM.

   Dữ liệu trong RAM có thể được copy vào Register hoặc Cache để tăng tốc độ truy xuất dữ liệu.

   Dữ liệu trong RAM sẽ mất khi mất điện.

4. Disk - SSD

   Ổ cứng SSD là nơi lưu dữ liệu lâu dài. Dữ liệu không mất khi mất điện.

   CPU không truy cập dữ liệu trực tiếp trong Disk mà sẽ được Load vào RAM để xử lý.

Sau đây chúng ta sẽ viết một chương trình c để xem tốc độ truy xuất dữ liệu của các loại bộ nhớ trên hệ điều hành Linux.

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>

#define LOOP            100000000

#define SMALL_SIZE      (32 * 1024)             // 32 KB (L1 Cache size)
#define LARGE_SIZE      (200 * 1024 * 1024)     // 200 MB (vượt qua kích thước của Cache)

#define CACHE_LINE      64                      // kích thước Cache Line là 64 byte

// Hàm lấy số giây đã trôi qua kể từ khi hệ thống khởi động
double now() {
    struct timespec t;
    clock_gettime(CLOCK_BOOTTIME, &t);
    return t.tv_sec + t.tv_nsec*1e-9;
}

int main() {
    double t;

    // 1. Mô phỏng thời gian CPU truy cập Cache
    // Mảng small được cấp phất một mảng đúng bằng 32KB vừa với kích thước của L1 Cache
    // do đó tỷ lệ Cache miss rất ít
    char* small = malloc(SMALL_SIZE);
    memset(small, 0, SMALL_SIZE);

    t = now();
    for (size_t i = 0; i < LOOP; i++)
    {
        // i * CACHE_LINE đảm bảo mỗi lần load dữ liệu ở một cache line mới
        small[(i * CACHE_LINE) % SMALL_SIZE]++;
    }
    printf("Thời gian truy cập Cache: %.3f ms\n", now() - t);

    // 2. Mô phỏng thời gian CPU truy cập RAM
    // Mảng large được cấp phát là 200 MB lớn hơn rất nhiều so với kích thước của L3 Cache
    // do đó sẽ xuất hiện Cache miss tương đối lớn
    char* larger = malloc(LARGE_SIZE);
    memset(larger, 0, LARGE_SIZE);

    t = now();
    for (size_t i = 0; i < LOOP; i ++)
    {
        larger[(i * CACHE_LINE) % LARGE_SIZE]++;
    }
    printf("Thời gian truy cập RAM: %.3f ms\n", now() - t);

    // 3. Mô phỏng thời gian hệ điều hành truy cập ổ cứng
    // Ghi mảng large ra file đồng bộ
    int fd = open("demo.bin", O_WRONLY | O_CREAT | O_TRUNC | O_SYNC, 0644);
    t = now();
    write(fd, larger, LARGE_SIZE);
    close(fd);
    printf("Thời gian ghi 200MB ra Disk: %.3f ms\n", now() - t);

    // Giải phóng bộ nhớ
    free(small);
    free(larger);

    return 0;
}

Kết quả:

Kết luận:

1. Mảng 32 KB có kích thước vừa với L1 Cache, tỷ lệ Cache miss thấp, thời gian truy cập rất nhanh

2. Mảng 200 MB vượt Cache size, nhiều Cache miss, CPU phải truy cập từ RAM, thời gian truy cập lâu hơn Cache

3. Ghi ra SSD là tầng thực sự chậm hơn RAM nhưng trên Linux SSD cũng có cache cho SSD trên RAM, hàm write() thực tế trả về ngay khi dữ liệu được ghi vào SSD cache nên thời gian 0.422 ms thực tế chưa phản ánh thời gian ghi file ra SSD.

The End.

Ở tầng kernel, khi có interrupt xảy ra, CPU sẽ tạm dừng luồng đang chạy để chuyển sang xử lý sự kiện ngắt. Sau khi hoàn tất, CPU quay lại tiếp tục công việc trước đó.
Tuy nhiên, ở tầng ứng dụng (user-space), một số sự kiện như tổ hợp phím Ctrl+C được hệ điều hành chuyển thành các thông báo (signal hoặc event), và cách chuyển cũng như xử lý các thông báo này khác nhau giữa Linux và Windows.

Ctrl+C trên Linux

Trên Linux, khi người dùng nhấn Ctrl+C

1. Kernel nhận ngắt từ bàn phím

2. Kernel chuyển sự kiện này thành signal SIGINT

3. Signal handler được thực thi trong chính context của thread nhận signal

Vì handler chạy trên luồng đang thực thi, nên trong thời gian xử lý signal, luồng chính bị tạm dừng.

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>

// Hàm xử lý signal SIGINT (Ctrl+C) ở user-space
void signint_handle(int sig) {
    printf("Đã nhận tín hiệu Ctrl+C %d\n", sig);
    // Nghỉ 5 giây
    sleep(5);
    printf("Đang quay lại công việc ...\n");
}

int main() {
    // Đăng kí handler xử lý signal SIGINT
    signal(SIGINT, signint_handle);

    printf("Chương trình đang chạy, nhấn Ctrl+C để gửi signal SIGINT ...\n");

    while (1)
    {
        printf("Đang làm việc ...\n");
        // Nghỉ 1 giây
        sleep(1);
    }

    return 0;
}

Kết quả, luồng chính bị block cho đến khi hàm xử lý SIGINT hoàn thành.

Ctrl+C trên Windows

Trên Windows, Ctrl+C không được chuyển thành signal như Linux.
Thay vào đó, Console Subsystem của Windows:

1. Bắt sự kiện CTRL_C_EVENT

2. Tạo một luồng nội bộ riêng gọi hàm đã đăng ký bằng SetConsoleCtrlHandler()

Do handler chạy trên luồng riêng, chương trình chính vẫn tiếp tục chạy song song.

#include <stdio.h>
#include <Windows.h>

// Hàm xử lý sự kiện Console Ctrl+C (CTRL_C_EVENT) trên thread riêng
BOOL WINAPI ConsoleHandler(DWORD dwControlType) {
    switch (dwControlType) {
        // Tổ hợp phím Ctrl+C được nhấn
    case CTRL_C_EVENT:
        printf("Đã nhận tín hiệu Ctrl+C\n");
        // Tạm dừng 5 giây
        Sleep(5000);
        printf("Đang quay lại công việc ...\n");
        return TRUE;
    default:
        return FALSE;
    }
}

int main() {
    // Ép Console sử dụng bảng mã UTF-8 (Code Page 65001) để Hiển thị tiếng việt
    SetConsoleOutputCP(65001);

    // Đăng kí handler xử lý sự kiện Ctrl+C của Console (user-space)
    if(SetConsoleCtrlHandler(ConsoleHandler, TRUE)) {
        printf("Chương trình đang chạy, nhấn Ctrl+C để gửi CTRL_C_EVENT ...\n");
        while (1)
        {
            printf("Đang làm việc ...\n");
            // Nghỉ 1 giây
            Sleep(1000);
        }
    }

    return 0;
}

Kết quả, luồng xử lý sự kiện Ctrl+C chạy song song với luồng chính

The End.