经典ASP：“应用程序”全局对象可以导致死锁吗？

Question

在经典ASP有一个全局对象，称为“应用程序”，它是由所有会话simultaniously访问。

由于“应用程序”对象是共享资源，它是否会导致死锁？

编辑：如果不是，为什么它锁定和解锁方法？ Reference

Answer 1

死锁与正常阻止不同。由于页面是在不同的线程中处理的，因此如果要防止其他请求修改该共享资源，则使用Lock，并且要再次进行修改，请使用Unlock方法。问题是，如果您不使用这些方法，另一个请求可以更改应用程序状态中某个项目的值，而您依赖的是旧值。或者两个请求可以尝试同时修改它，并且可能会导致问题。 Lock方法会导致请求等待，直到其他请求解锁应用程序;之后，它可以继续。

死锁是其中线程A锁资源1​​个和等待为资源2变得可用的情况。与此同时线程B，这锁定资源2只需要访问资源1​​（由线程A锁定）继续工作，并能够在事后释放资源。在这种情况下，无的线程可以继续（其中一个必须终止以允许继续）。这是一个死锁。如果正确使用，Application.Lock本身不会造成死锁。但是，如果使用不当，可能会导致死锁（当与另一个需要锁定的共享资源结合使用时，并且不会考虑死锁）。

Answer 2

不，它从不阻止。

Answer 3

死锁是一种情况，其中两个或更多竞争行为正在等待另一个完成，因此从来没有这样做。

Answer 4

锁定ASP Application对象不太可能导致持续时间超过服务器脚本超时设置的死锁。

传统的ASP Application对象具有锁定和解锁，用于同步对应用程序对象的更改。您可以有多个请求尝试对相同的值进行更改 - 不锁定，更改并解锁更改可能会丢失。

就像一个简单的例子就是某种计数器。比方说，你的代码做：

<% 
Application("Count") = Application("Count") + 1 
%> 

如果你有两个同时请求（REQ1和REQ2），你可以“丢失”分页命中 - 实际上是一个“缺少更新”。

可以防止这种通过更新，并在更新后解锁它之前锁定Application变量：

<% 
Application.Lock 
Application("Count") = Application("Count") + 1 
Application.Unlock 
%> 

如果Application而另一个请求线程试图访问被锁定，该线程将被阻塞，直到锁被释放或超出脚本超时。

如果您忘记解锁一个锁，它将在页面处理后或超过脚本超时后自动释放。

欲了解更多信息，see MSDN。