问一个关于锁的有关问题
问一个关于锁的问题。
假设某个list变量：_mylist，在对_mylist增删改的时候都加了锁，
然后，在查询这个_mylist的时候，比如：
我的问题是：
当执行这句_mylist.FindAll的时候，若同时_mylist正在锁内执行增加操作，那么_mylist.FindAll会等待锁释放吗？还是不等待？
------解决思路----------------------
读的时候也要加锁，List<T>不保证并发的完整性和一致性
------解决思路----------------------
不等待，锁的是你的增删改过程，不是这个对象。
------解决思路----------------------
所谓的阻塞式的lock，就是在 lock(...) 这条语句上去阻塞其所在线程的执行进度的。哪来的什么“那么_mylist.FindAll会等待锁释放”之类的说法呢？操作系统没有你说的那么强大的智慧，如果有的话，对于复杂的程序，那么必将付出“降低运行效率10000倍”的代价才能勉强得到。
而你瞎猜则可以随便天马行空地去瞎猜，完全不学习实际的机制。
------解决思路----------------------
#4都说的很清楚了，还要再问一遍干嘛？
------解决思路----------------------
在微软的示例里面，不仅要将锁对象设为私有，还要设为只读，自己想一想为何要设为只读，就知道你这样做是否合适了。
假设某个list变量：_mylist，在对_mylist增删改的时候都加了锁，
然后，在查询这个_mylist的时候，比如：
_mylist.FindAll(p => p.NeedPlayAreasEN.Trim() == AreasEN.Trim() && p.Status.Trim() != "PlayIsEnd")
我的问题是：
当执行这句_mylist.FindAll的时候，若同时_mylist正在锁内执行增加操作，那么_mylist.FindAll会等待锁释放吗？还是不等待？
------解决思路----------------------
读的时候也要加锁，List<T>不保证并发的完整性和一致性
------解决思路----------------------
不等待，锁的是你的增删改过程，不是这个对象。
------解决思路----------------------
所谓的阻塞式的lock，就是在 lock(...) 这条语句上去阻塞其所在线程的执行进度的。哪来的什么“那么_mylist.FindAll会等待锁释放”之类的说法呢？操作系统没有你说的那么强大的智慧，如果有的话，对于复杂的程序，那么必将付出“降低运行效率10000倍”的代价才能勉强得到。
而你瞎猜则可以随便天马行空地去瞎猜，完全不学习实际的机制。
------解决思路----------------------
#4都说的很清楚了，还要再问一遍干嘛？
------解决思路----------------------
在微软的示例里面，不仅要将锁对象设为私有，还要设为只读，自己想一想为何要设为只读，就知道你这样做是否合适了。