2013-07-23 52 views
6

tôi đã đưa ra những điểm sau đây từ API này và tôi muốn biết sự khác biệt giữa 2 điểm sau đây:đề tín hiệu trong điều kiện của một khóa

  1. đề chờ được hiệu theo thứ tự FIFO.

  2. Trật tự của khóa reacquisition cho chủ đề trở về từ phương pháp chờ đợi là như nhau như đối với chủ đề ban đầu mua lại các khóa , đó là trong trường hợp mặc định không quy định, nhưng đối với ổ khóa bằng ủng hộ những chủ đề đã được chờ đợi dài nhất.

Nó có liên quan đến Condition lớp mà thường được trả theo phương pháp ReentrantLock .newCondition(), và các bit tôi trích dẫn nó giải thích sự khác biệt giữa các phương pháp Condition và các phương pháp giám sát thường xuyên của lớp Object.

"Chuỗi chờ được báo hiệu theo thứ tự FIFO". Tôi nghĩ rằng miễn là một lock được tạo ra một trong hai công bằng hay không, thực tế là các chủ đề chờ đợi được báo hiệu trong một trật tự FIFO là hoàn toàn không liên quan isn'it? bởi vì dù sao đi chăng nữa, liệu họ có được xây dựng, công bằng hay không, quyết định họ xếp hàng như thế nào.

Chỉ yêu cầu xác nhận.

Xin cảm ơn trước.

Trả lời

1

Xin vui lòng xem bên dưới câu trả lời cho câu hỏi của bạn:

đề 1.Waiting được hiệu theo thứ tự FIFO.

Khi chúng tôi gọi phương thức await() của Điều kiện, luồng đi vào trạng thái chờ, câu lệnh trên đề cập đến cách các luồng trong trạng thái chờ được báo hiệu. Vì vậy, nếu chủ đề T1 đã đi đến trạng thái chờ trước T2, T1 sẽ được báo hiệu trước T2.

2.The Trật tự của khóa reacquisition cho chủ đề trở về từ phương pháp chờ đợi là như nhau như đối với chủ đề ban đầu mua lại các khóa, đó là trong trường hợp mặc định không quy định, nhưng đối với ổ khóa bằng ủng hộ những chủ đề đã được chờ đợi dài nhất.

Khi tiếp tục tuyên bố ở trên, khi chuỗi chờ được báo hiệu, nó có xu hướng yêu cầu khóa lại. Mặc dù tuyên bố trên nói rằng T1 sẽ được báo hiệu trước T2, nhưng khi nói đến việc khóa lại, thứ tự phản ứng sử dụng các khái niệm được định nghĩa bởi Khóa. Vì vậy, nó phụ thuộc vào cách đối tượng Khóa được tạo ra. Trong khi tạo Khóa bạn có thể đã xác định một tham số công bằng:

ReentrantLock(boolean fair)

Nếu có thì tham số được sử dụng, nếu không thì mặc định hành vi của ổ khóa sẽ xảy ra, bạn có thể đọc thêm về ReentrantLock Locks tại này link

Có thể có nhiều giải thích hơn cho những phát biểu này, chỉ cố gắng trình bày chi tiết nhất sự hiểu biết của tôi ở đây. Hy vọng đã có thể làm rõ.

Chúc mừng !!

0

Miễn là khóa được tạo công bằng hay không, thực tế là các chuỗi chờ được báo hiệu theo thứ tự FIFO là hoàn toàn không liên quan, phải không? Bởi vì dù sao đi chăng nữa, liệu họ có được xây dựng, công bằng hay không, quyết định họ xếp hàng như thế nào.

Tôi nghĩ nó có liên quan.

Hãy xem xét kịch bản trong đó T1 và T2 đang chờ điều kiện C (với T1 chờ lâu hơn T2), T3 đang chạy bên trong màn hình và T4 đang chờ mua khóa ban đầu. Tín hiệu T3 C và để màn hình nhả khóa. Giả sử không có đánh thức giả mạo xảy ra.

Nếu khóa là công bằng, T4 chắc chắn sẽ lấy khóa trước T1, nhưng thực tế là các chuỗi chờ được báo hiệu theo thứ tự FIFO sẽ đảm bảo rằng T1 sẽ lấy khóa trước T2.

Ngoài ra, nếu khóa là không công bằng, chúng tôi không thể nói chuỗi nào sẽ nhận khóa đầu tiên giữa T1 và T4, nhưng một lần nữa thực tế là các chuỗi chờ được báo hiệu theo thứ tự FIFO đảm bảo rằng T1 sẽ thu được khóa trước T2, không có tín hiệu nào khác xảy ra cho đến khi T1 nhận được khóa (ví dụ trong trường hợp T1 chịu trách nhiệm về tín hiệu tiếp theo).

0

Tôi nghĩ mã nguồn có thể cung cấp cho chúng tôi nhiều manh mối hơn về cách hoạt động của nó. ReentrantLock.newCondition() trả lại ConditionObject trong AbstractQueuedSynchronizer .Đây là liên kết mã nguồn AQS source code.

1.Chủ đề đang chờ được báo hiệu theo thứ tự FIFO.

Có hai hàng đợi trong AbstractQueuedSynchronizer.

Một là vì đã chờ đợi khóa (chỉ gọi nó lock chờ đợi), bạn sẽ thấy hai dễ bay hơi biến đầuđuôi trong định nghĩa lớp AbstractQueuedSynchronizer 's, và tham số công bằng sẽ ảnh hưởng này behavior.When hàng đợi của bạn mới một hội chợ ReentrantLock và gọi Acquire, AQS sẽ gọi FairSync 's tryAcquire để kiểm tra xem chủ đề hiện nay là chủ đề đầu tiên chờ đợi trong khóa chờ đợi, xem hasQueuedPredecessors.

hàng đợi khác là hàng đợi tín hiệu trong định nghĩa của ConditionObject, bạn sẽ thấy hai biến firstWaiterlastWaiter .Khi chờ được gọi, một nút sẽ thêm vào đuôi của hàng đợi và Khi tín hiệu được gọi là, một nút từ đầu sẽ được dequeued và thêm vào hàng chờ đợi khóa để reacquire khóa.Thêm vào hàng chờ đợi khóa không có nghĩa là nó sẽ được tỉnh dậy, nhưng một khóa .mở khóa() sẽ được gọi sau khi tín hiệu , sẽ đánh thức người phục vụ, xem unparkSuccessor.

2.The Trật tự của khóa reacquisition cho chủ đề trở về từ phương pháp chờ đợi là như nhau như đối với chủ đề ban đầu mua lại các khóa, đó là trong trường hợp mặc định không quy định, nhưng đối với ổ khóa bằng ủng hộ những chủ đề đã được chờ đợi dài nhất.

thức dậy từ chờ phương pháp không có nghĩa là để giữ khóa, nó sẽ gọi acquireQueued để reacquire khóa và có thể được đậu lại. Theo hiểu biết của tôi, thứ tự ban đầu có được khóa giống như thứ tự gọi đang chờ, vì vậy giống như thứ tự gọi purchaseQueued, Điều gì khiến tôi nhầm là nhưng đối với khóa công bằng chờ đợi lâu nhất., Khi thức dậy từ chờ, theo ý kiến ​​của tôi, nó sẽ là chủ đề đầu tiên trong khóa đợi chờ, Khi gọi acquireQueued và kiểm tra p == đầu & & tryAcquire (arg), khóa công bằng hoặc không có hiệu lực.

Hy vọng điều này sẽ giúp và cho tôi biết nếu tôi sai.