Đồng thời

01 Vì sao đồng thời?

Đồng thời (concurrency) là một chiến lược tách rời (decoupling): tách "cái gì" (what) khỏi "khi nào" (when). Trong code đơn luồng, what & when gắn chặt — nhìn ngăn xếp (call stack) là biết ngay trạng thái hệ thống. Tách hai thứ đó ra giúp cải thiện cả throughput lẫn cấu trúc: hệ thống trông như nhiều máy tính nhỏ cộng tác, thay vì một vòng lặp chính (main loop) khổng lồ.

RAG  Trong hệ RAG, khâu hỏi-đáp tài liệu cũng đầy chỗ phải chờ I/O — truy hồi vector store, gọi API mô hình, đọc nguồn. Phục vụ nhiều truy vấn đồng thời tận dụng các khoảng chờ này để tăng throughput, miễn là ta tách bạch "cái gì cần làm" khỏi "khi nào nó chạy".

02 Lầm tưởng & sự thật

Concurrency mang theo nhiều ngộ nhận tai hại. Ba lầm tưởng phổ biến nhất — và sự thật đi kèm:

03 Thử thách: ++ không nguyên tử

Một ví dụ nhỏ đủ cho thấy các luồng "giẫm chân" nhau ra sao. Giả sử lastIdUsed = 42 và hai luồng cùng gọi get_next_id() với phép ++ trần (không bảo vệ). Có ba kết cục khả dĩ: luồng A nhận 43 & B nhận 44 (biến thành 44); A nhận 44 & B nhận 43 (biến thành 44); hoặc cả hai cùng nhận 43 và biến chỉ thành 43 — mất một lần tăng.

RAG  Trong hệ RAG, một bộ đếm dùng chung — ví dụ cấp document id khi nạp tài liệu song song, hay đếm số truy vấn — chính là cái bẫy này. Bỏ ++ trần, dùng đồng bộ hóa hoặc kiểu atomic:

class IdSource:
    def __init__(self):
        self.last_id = 42

    def next_id(self):
        self.last_id += 1        # ✗ ++ không nguyên tử
        return self.last_id      # 2 luồng → có thể MẤT một lần tăng

class IdSource:
    def __init__(self):
        self.last_id = 42
        self.lock = Lock()

    def next_id(self):
        with self.lock:          # ✓ critical section được bảo vệ
            self.last_id += 1
            return self.last_id  # (hoặc dùng counter atomic của thư viện)

04 Nguyên tắc phòng thủ

Martin đưa ra một bộ nguyên tắc & kỹ thuật để hạn chế rủi ro của code đồng thời. Bốn nguyên tắc nền tảng:

RAG  Áp vào RAG: thay vì để nhiều luồng cùng ghi vào một store/registry dùng chung trong lúc nạp, cho mỗi luồng xử lý độc lập trên bản sao rồi gộp kết quả ở một luồng duy nhất:

shared_index = {}                  # ✗ dữ liệu chia sẻ khắp nơi

def worker(docs):
    for d in docs:
        shared_index[d.id] = embed(d.text)   # nhiều luồng cùng ghi
        global_stats.count += 1              # ✗ và cùng tăng đếm chung

def worker(docs):
    local = {}                     # ✓ mỗi luồng dùng bản sao cục bộ
    for d in docs:
        local[d.id] = embed(d.text)
    return local                   # gộp các bản sao trong MỘT luồng

def merge(results):                # phạm vi sửa dữ liệu chung thu về 1 nơi
    index = {}
    for part in results: index.update(part)
    return index

05 Hiểu thư viện & mô hình thực thi

Know your library. Trước khi tự tay viết khóa, hãy tận dụng công cụ có sẵn:

Know your execution models — ba mô hình kinh điển

Học ba mô hình thực thi này để nhận ra & giải các bài toán cạnh tranh tài nguyên thường gặp:

06 Section đồng bộ, shutdown & test code đa luồng

synchronized tạo ra một lock; mọi đoạn dùng cùng lock chỉ cho một luồng chạy tại một thời điểm. Lock đắt (gây delay + overhead), nên đừng rải synchronized khắp nơi; nhưng critical section thì bắt buộc phải bảo vệ.

Viết code shutdown đúng là khó

Viết một hệ chạy mãi khác hẳn viết một hệ chạy rồi tắt duyên dáng (graceful shutdown). Shutdown dễ deadlock: một luồng cha sinh nhiều luồng con rồi đợi tất cả xong — chỉ một con kẹt là cha đợi mãi; hoặc producer nhận tín hiệu tắt & dừng nhanh, để consumer còn đang chờ message bị kẹt, không nhận được tín hiệu tắt. Lời khuyên: nghĩ về shutdown sớm và làm cho nó chạy đúng sớm — việc này lâu hơn bạn tưởng.

Test code đa luồng

Không thể chứng minh code đa luồng đúng; test tốt chỉ giảm rủi ro. Vài lời khuyên cốt lõi:

07 Ghi nhớ nhanh