Gọi pthread_cond_signal mà không khóa mutex

Tôi đọc ở đâu đó rằng chúng ta nên khóa mutex trước khi gọi pthread_cond_signal và mở khóa mutext sau khi gọi nó:

Quy trình pthread_cond_signal () được sử dụng để báo hiệu (hoặc đánh thức) một luồng khác đang chờ biến điều kiện. Nó sẽ được gọi sau khi khóa mutex và phải mở khóa mutex để quy trình pthread_cond_wait () hoàn tất.

Câu hỏi của tôi là: phải không OK để gọi pthread_cond_signal hoặc pthread_cond_broadcast phương pháp mà không cần khóa mutex?

Nếu bạn không khóa mutex trong đường dẫn thay đổi điều kiện và tín hiệu, bạn có thể mất đánh thức. Hãy xem xét cặp quy trình này:

Quy trình A:

pthread_mutex_lock(&mutex);
while (condition == FALSE)
    pthread_cond_wait(&cond, &mutex);
pthread_mutex_unlock(&mutex);

Quy trình B (không chính xác):

condition = TRUE;
pthread_cond_signal(&cond);

Sau đó, hãy xem xét sự đan xen có thể có của các hướng dẫn này, conditionbắt đầu như FALSE:

Process A                             Process B

pthread_mutex_lock(&mutex);
while (condition == FALSE)

                                      condition = TRUE;
                                      pthread_cond_signal(&cond);

pthread_cond_wait(&cond, &mutex);

Hiện conditiontại là TRUE, nhưng Quy trình A bị kẹt khi chờ biến điều kiện - nó đã bỏ lỡ tín hiệu đánh thức. Nếu chúng tôi thay đổi Quy trình B để khóa mutex:

Quy trình B (đúng):

pthread_mutex_lock(&mutex);
condition = TRUE;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);

... thì điều trên không thể xảy ra; thức dậy sẽ không bao giờ bị bỏ lỡ.

(Lưu ý rằng bạn thực sự có thể di chuyển pthread_cond_signal()chính nó sau pthread_mutex_unlock(), nhưng điều này có thể dẫn đến việc lập lịch các luồng kém tối ưu hơn và bạn nhất thiết phải khóa mutex đã có trong đường dẫn mã này do chính điều kiện thay đổi).

Theo hướng dẫn này:

Các pthread_cond_broadcast()hoặc các pthread_cond_signal()hàm có thể được gọi bởi một luồng cho dù nó hiện đang sở hữu mutex mà các luồng đang gọi pthread_cond_wait() hoặc pthread_cond_timedwait()có liên kết với biến điều kiện trong thời gian chờ của chúng hay không; tuy nhiên, nếu hành vi lập lịch dự đoán được yêu cầu, thì mutex đó sẽ bị khóa bởi luồng gọi pthread_cond_broadcast()hoặc pthread_cond_signal().

Ý nghĩa của câu lệnh hành vi lập lịch có thể dự đoán được đã được Dave Butenhof (tác giả của Lập trình với các luồng POSIX ) giải thích trên comp.programming.threads và có sẵn tại đây .

caf, trong mã mẫu của bạn, Quy trình B sửa đổi conditionmà không khóa mutex trước. Nếu Quy trình B chỉ đơn giản là khóa mutex trong quá trình sửa đổi đó, và sau đó vẫn mở khóa mutex trước khi gọi pthread_cond_signal, sẽ không có vấn đề gì --- tôi có đúng về điều đó không?

Tôi tin trực giác rằng vị trí của caf là đúng: gọi điện pthread_cond_signalmà không sở hữu khóa mutex là một Ý tưởng Xấu. Nhưng ví dụ của caf thực sự không phải là bằng chứng ủng hộ quan điểm này; nó chỉ đơn giản là bằng chứng ủng hộ quan điểm yếu hơn nhiều (thực tế là hiển nhiên) rằng việc sửa đổi trạng thái được chia sẻ được bảo vệ bởi mutex là một Ý tưởng Xấu, trừ khi bạn đã khóa mutex đó trước.

Bất cứ ai có thể cung cấp một số mã mẫu trong đó lệnh gọi pthread_cond_signaltheo sau pthread_mutex_unlockmang lại hành vi đúng, nhưng gọi pthread_mutex_unlocktheo sau là pthread_cond_signalhành vi không chính xác?