Mặc dù các chủ đề dường như là một bước nhỏ từ tính toán tuần tự, trên thực tế, chúng đại diện cho một bước rất lớn. Họ loại bỏ các tính chất cần thiết và hấp dẫn nhất của tính toán tuần tự: dễ hiểu, dự đoán và xác định. Các chủ đề, như là một mô hình tính toán, cực kỳ không phổ biến, và công việc của lập trình viên trở thành một trong những cách cắt tỉa không thuyết phục đó.
- Vấn đề với chủ đề (www.eecs.ber siêu.edu / Pub / TechRpts / 2006 / EECS-2006-1.pdf).
Mặc dù có một số lợi thế về hiệu suất có thể có bằng cách sử dụng các luồng trong đó bạn có thể phân phối công việc trên nhiều lõi, chúng thường có giá rất cao.
Một trong những nhược điểm của việc sử dụng các luồng chưa được đề cập ở đây là việc mất khả năng phân chia tài nguyên mà bạn nhận được với các không gian xử lý luồng đơn. Ví dụ, giả sử bạn gặp phải trường hợp segfault. Trong một số trường hợp, có thể phục hồi từ điều này trong một ứng dụng đa quy trình ở chỗ bạn chỉ cần để đứa trẻ bị lỗi chết đi và hồi sinh một cái mới. Đây là trường hợp trong phần phụ trợ prefork của Apache. Khi một cá thể httpd gặp khó khăn, trường hợp xấu hơn là yêu cầu HTTP cụ thể có thể bị loại bỏ cho quá trình đó nhưng Apache sinh ra một đứa trẻ mới và thường là yêu cầu nếu chỉ bực bội và được phục vụ. Kết quả cuối cùng là toàn bộ Apache không bị gỡ xuống với luồng bị lỗi.
Một xem xét khác trong kịch bản này là rò rỉ bộ nhớ. Có một số trường hợp bạn có thể xử lý một sự cố một cách duyên dáng (trên UNIX, phục hồi từ một số tín hiệu cụ thể - thậm chí segfault / fpviolation - có thể), nhưng ngay cả trong trường hợp đó, bạn có thể đã rò rỉ tất cả bộ nhớ được phân bổ bởi luồng đó (malloc, mới, v.v.). Vì vậy, trong khi bạn xử lý có thể tồn tại, nó sẽ rò rỉ bộ nhớ ngày càng nhiều theo thời gian với mỗi lỗi / phục hồi. Một lần nữa, có một số cách để giảm thiểu điều này như việc sử dụng nhóm bộ nhớ của Apache. Nhưng điều này vẫn không bảo vệ chống lại bộ nhớ có thể được phân bổ bởi các lib của bên thứ ba mà luồng có thể đang sử dụng.
Và, như một số người đã chỉ ra, hiểu được nguyên thủy đồng bộ hóa có lẽ là điều khó nhất để thực sự đúng. Vấn đề này tự nó - chỉ cần có logic chung cho tất cả mã của bạn - có thể là một vấn đề đau đầu. Những bế tắc bí ẩn có xu hướng xảy ra vào những thời điểm kỳ lạ nhất, và đôi khi thậm chí là cho đến khi chương trình của bạn đang chạy trong sản xuất, điều này khiến việc gỡ lỗi trở nên khó khăn hơn. Thêm vào đó là thực tế rằng các nguyên thủy đồng bộ hóa thường khác nhau nhiều so với nền tảng (Windows so với POSIX) và việc gỡ lỗi thường có thể khó khăn hơn, cũng như khả năng cho các điều kiện cuộc đua bất cứ lúc nào (khởi động / khởi tạo, thời gian chạy và tắt máy), lập trình với các chủ đề thực sự có chút thương xót cho người mới bắt đầu. Và ngay cả đối với các chuyên gia, Vẫn còn chút thương xót chỉ vì kiến thức về luồng tự nó không giảm thiểu sự phức tạp nói chung. Mỗi dòng mã đôi khi dường như gộp theo cấp số nhân độ phức tạp chung của chương trình cũng như tăng xác suất cho một bế tắc ẩn hoặc điều kiện cuộc đua kỳ lạ xuất hiện bất cứ lúc nào. Cũng có thể rất khó để viết các trường hợp thử nghiệm để loại bỏ những thứ này ra.
Đây là lý do tại sao một số dự án như Apache và PostgreSQL dành cho hầu hết các phần dựa trên quy trình. PostgreSQL chạy mọi luồng phụ trợ trong một quy trình riêng biệt. Tất nhiên điều này vẫn không làm giảm bớt vấn đề đồng bộ hóa và điều kiện chủng tộc, nhưng nó có thêm một chút bảo vệ và trong một số cách đơn giản hóa mọi thứ.
Nhiều tiến trình, mỗi tiến trình chạy một luồng thực thi có thể tốt hơn nhiều luồng chạy trong một tiến trình. Và với sự ra đời của nhiều mã ngang hàng mới như AMQP (RabbitMQ, Qpid, v.v.) và ZeroMQ, việc phân chia các luồng trên các không gian xử lý khác nhau và thậm chí cả máy móc và mạng, đơn giản hóa rất nhiều thứ. Nhưng vẫn không phải là viên đạn bạc. Vẫn còn phức tạp để giải quyết. Bạn chỉ cần di chuyển một số biến của mình từ không gian xử lý vào mạng.
Điểm mấu chốt là quyết định nhập vào miền của các luồng không phải là một quyết định nhẹ. Một khi bạn bước vào lãnh thổ đó, gần như ngay lập tức mọi thứ trở nên phức tạp hơn và những vấn đề hoàn toàn mới xâm nhập vào cuộc sống của bạn. Nó có thể vui vẻ và tuyệt vời, nhưng nó giống như năng lượng hạt nhân - khi mọi thứ trở nên tồi tệ, chúng có thể trở nên tồi tệ và nhanh chóng. Tôi nhớ đã tham gia một lớp đào tạo về phê bình nhiều năm trước và họ đã cho thấy hình ảnh của một số nhà khoa học tại Los Alamos, người đã chơi với plutonium trong các phòng thí nghiệm trong Thế chiến II. Nhiều người đã thực hiện rất ít hoặc không có biện pháp phòng ngừa đối với sự kiện phơi nhiễm và trong chớp mắt - trong một chớp sáng, không đau, tất cả sẽ kết thúc với họ. Mấy ngày sau họ chết. Richard Feynman sau này gọi điều này là " cù đuôi rồng"Đó là kiểu chơi với các chủ đề có thể giống như (ít nhất là đối với tôi). Lúc đầu, nó có vẻ khá vô hại, và khi bạn bị cắn, bạn gãi đầu về việc mọi thứ trở nên chua chát. Nhưng ít nhất thì các chủ đề đã thắng Sẽ không giết bạn.