问：为了可以顺序访问Session的状态值，Session是否提供了锁定机制？
答：Session实现了Reader/Writer的锁机制：
当页面对Session具有可写功能（即页面有<%@Page EnableSessionState="True" %>标记），此时直到请求完成该页面的Session持有一个写锁定。
当页面对Session具有只读功能（即页面有<%@Page EnableSessionState="ReadOnly" %>标记），此时知道请求完成该页面的Session持有一个读锁定。
读锁定将阻塞一个写锁定；读锁定不会阻塞读锁定；写锁定将阻塞所有的读写锁定。这就是为什么两个框架中的同一个页面都去写同一个Session时，其中一个要等待另一个（稍快的那个）完成后，才开始写。
webform：
“写锁定将阻塞所有的读写锁定”，也就是说页面在EnableSessionState="True"的情况下没返回输出时，一直持着Session写操作，其他页面对Session的读操作必须等待，而asp.net的aspx页面默认是EnableSessionState="True"，每个页面从请求开始至返回一直持着Session写操作，需验证页面必须读取Session值判断，这就是为什么需验证的页面请求被阻塞的原因。只要耗时页面（A页面）没有Session的写操作，也就不会阻塞其他页面的请求，于是修改A页面的EnableSessionState="ReadOnly"，
例如：<%@ Page Language="C#" AutoEventWireup="true"CodeFile="Demo_List.aspx.cs"EnableSessionState="ReadOnly" Inherits="Demo_List" %> ，问题解决。
也就是说，在无需对session进行写操作的页面，加上EnableSessionState="ReadOnly"属性，就不会造成Request阻塞的情况了。
mvc：
为Controller增加以下特性，但是此Controller都不能修改Session了，只能读取。
[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]