Một đối tượng bị khóa có bị khóa không nếu một ngoại lệ xảy ra bên trong nó?

Question 1

Trong ứng dụng ac # threading, nếu tôi khóa một đối tượng, chúng ta hãy nói một hàng đợi và nếu một ngoại lệ xảy ra, đối tượng có bị khóa không? Đây là mã giả:

int ii;
lock(MyQueue)
{
   MyClass LclClass = (MyClass)MyQueue.Dequeue();
   try
   {
      ii = int.parse(LclClass.SomeString);
   }
   catch
   {
     MessageBox.Show("Error parsing string");
   }
}

Theo tôi hiểu, mã sau khi bắt không thực thi - nhưng tôi đã tự hỏi liệu khóa có được giải phóng hay không.

Question 2

Đầu tiên; bạn đã coi TryParse chưa?

in li;
if(int.TryParse(LclClass.SomeString, out li)) {
    // li is now assigned
} else {
    // input string is dodgy
}

Khóa sẽ được phát hành vì 2 lý do; đầu tiên, lockvề cơ bản là:

Monitor.Enter(lockObj);
try {
  // ...
} finally {
    Monitor.Exit(lockObj);
}

Thứ hai; bạn nắm bắt và không ném lại ngoại lệ bên trong, vì vậy lockkhông bao giờ thực sự thấy ngoại lệ. Tất nhiên, bạn đang giữ khóa trong thời gian của MessageBox, điều này có thể là một vấn đề.

Vì vậy, nó sẽ được phát hành trong tất cả các trường hợp ngoại lệ không thể phục hồi thảm họa chết người nhất.

Question 3

Tôi lưu ý rằng không ai đã đề cập trong câu trả lời của họ cho câu hỏi cũ này rằng việc giải phóng khóa khi có ngoại lệ là một điều cực kỳ nguy hiểm. Có, các câu lệnh khóa trong C # có ngữ nghĩa "cuối cùng"; khi điều khiển thoát ra khỏi khóa bình thường hoặc bất thường, khóa sẽ được giải phóng. Tất cả các bạn đang nói về điều này như thể nó là một điều tốt, nhưng nó là một điều xấu! Điều đúng đắn cần làm nếu bạn có một vùng bị khóa tạo ra một ngoại lệ không được xử lý là chấm dứt quá trình bị bệnh ngay lập tức trước khi nó phá hủy nhiều dữ liệu người dùng hơn , không giải phóng khóa và tiếp tục .

Hãy nhìn nó theo cách này: giả sử bạn có một phòng tắm với khóa cửa và một dòng người đang đợi bên ngoài. Một quả bom trong phòng tắm nổ tung, giết chết một người trong đó. Câu hỏi của bạn là "trong tình huống đó khóa sẽ tự động mở để người tiếp theo có thể vào phòng tắm?" Nó sẽ được thôi. Đó không phải là một điều tốt. Một quả bom đã nổ trong đó và giết một người! Hệ thống ống nước có thể đã bị phá hủy, ngôi nhà không còn chắc chắn về mặt cấu trúc, và có thể có một quả bom khác trong đó . Việc cần làm là đưa mọi người ra ngoài càng nhanh càng tốt và phá dỡ toàn bộ ngôi nhà.

Ý tôi là, hãy suy nghĩ kỹ: nếu bạn đã khóa một vùng mã để đọc từ cấu trúc dữ liệu mà nó không bị biến đổi trên một luồng khác và một cái gì đó trong cấu trúc dữ liệu đó đã đưa ra một ngoại lệ, thì rất tốt đó là do cấu trúc dữ liệu là tham nhũng . Dữ liệu người dùng bây giờ bị rối tung; bạn không muốn cố gắng lưu dữ liệu người dùng tại thời điểm này vì khi đó bạn đang lưu dữ liệu bị hỏng . Chỉ cần chấm dứt quá trình.

Nếu bạn đã khóa một vùng mã để thực hiện đột biến mà không có luồng khác đọc trạng thái đồng thời và đột biến ném, thì nếu dữ liệu không bị hỏng trước đây, thì chắc chắn là bây giờ . Đó chính xác là kịch bản mà khóa được cho là để bảo vệ chống lại . Bây giờ mã đang chờ đọc trạng thái đó sẽ ngay lập tức được cấp quyền truy cập vào trạng thái bị hỏng, và có thể chính nó bị sập. Một lần nữa, điều đúng đắn cần làm là chấm dứt quá trình.

Bất kể bạn cắt nó như thế nào, một ngoại lệ bên trong ổ khóa là một tin xấu . Câu hỏi phù hợp để hỏi không phải là "ổ khóa của tôi có được dọn dẹp trong trường hợp ngoại lệ không?" Câu hỏi phù hợp cần đặt ra là "làm cách nào để đảm bảo rằng không bao giờ có ngoại lệ bên trong khóa? Và nếu có, thì làm cách nào để cấu trúc chương trình của mình để các đột biến được khôi phục về trạng thái tốt trước đó?"

Question 4

vâng, điều đó sẽ phát hành đúng cách; lockhoạt động như try/ finally, với Monitor.Exit(myLock)cuối cùng, vì vậy bất kể bạn thoát bằng cách nào, nó sẽ được phát hành. Như một lưu ý phụ, catch(... e) {throw e;}tốt nhất là nên tránh, vì điều đó làm hỏng dấu vết ngăn xếp trên e; nó là tốt hơn không bắt nó ở tất cả , hoặc cách khác: sử dụng throw;chứ không phải throw e;mà hiện một tái ném.

Nếu bạn thực sự muốn biết, khóa trong C # 4 / .NET 4 là:

{
    bool haveLock = false;
    try {
       Monitor.Enter(myLock, ref haveLock);
    } finally {
       if(haveLock) Monitor.Exit(myLock);
    }
}

Question 5

"Một câu lệnh khóa được biên dịch thành một lệnh gọi tới Monitor.Enter, sau đó là một khối try ... last. Trong khối cuối cùng, Monitor.Exit được gọi.

Việc tạo mã JIT cho cả x86 và x64 đảm bảo rằng việc hủy bỏ luồng không thể xảy ra giữa một lệnh gọi Monitor.Enter và một khối thử ngay sau đó. "

Lấy từ: Trang web này

Question 6

Khóa của bạn sẽ được phát hành đúng cách. A lockhoạt động như thế này:

try {
    Monitor.Enter(myLock);
    // ...
} finally {
    Monitor.Exit(myLock);
}

Và finallycác khối được đảm bảo sẽ thực thi, bất kể bạn rời trykhối bằng cách nào .

Question 7

Chỉ để thêm một chút vào câu trả lời xuất sắc của Marc.

Những tình huống như thế này là lý do chính cho sự tồn tại của locktừ khóa. Nó giúp các nhà phát triển đảm bảo khóa được phát hành trong finallykhối.

Nếu bạn buộc phải sử dụng Monitor.Enter/ Exitví dụ: để hỗ trợ thời gian chờ, bạn phải đảm bảo thực hiện lệnh gọi đến Monitor.Exittrong finallykhối để đảm bảo khóa đúng cách trong trường hợp có ngoại lệ.