我正在开发一个类似SVN的系统（基本上有login / logout + put / get / list / delete命令），它应该接受来自多个客户端的命令。我的想法是将所有收到的命令放在一个（阻塞）队列式结构中，它将在不同的线程上顺序执行它们。
后来，有了更多的时间，我可以设计一些智能机制来理解是否可以同时执行一个或多个下一个队列消息，这样我就可以加快一点过程（例如，如果我有两个命令队列是在不同的项目上工作，没有竞争条件/共享数据问题。）
我现在面临的问题是，这是否真的是问题的最佳解决方案。我可以锁定文件，因为我正在使用它们，但我担心这可能会导致某些特定的极端情况出现死锁（尽管我仍然无法想到可能发生的具体情况）。
此项目将用于网络安全类。因此，这个SVN事件只是我后来奠定我安全问题核心的基础。我不认为性能是最重要的（但确保死锁不会发生！），因此目标目标是算法正确性。
你会如何处理这种情况？
答案 0 :(得分：1)
我做过几个类似性质的项目。在一次迭代中，我们在将它们传输到客户端之前复制了服务器上的文件。而对于相反的方向，我们在覆盖主文件之前流式传输到临时文件。这是一团糟。不要那样做！如今典型的互联网连接并不比磁盘慢得多，典型的磁盘传输通常比普通的LAN连接慢。另外，你是否在这个东西中存储（通常很小的）源代码文件？文件锁定足以保护文件。如今，每个库都支持系统级文件锁定。 （如果你不相信我，请查看.Net中FileStream的构造函数重载。）如果需要写入数据，则尝试获取所有必需文件的写锁定。如果无法完成，则向用户返回超时错误。我工作的一个系统有永久的只读文件，如果你希望人们能够整天流式传输某个文件，你可以使用那个标志。如果文件锁定确实不足，您可以查看.Net ReaderWriterLock类。
我看不到手动排队put / get / delete请求有什么好处。这是服务器的工作，而不是你的工作。您不希望将所有“放入”数据保存在RAM中。如果可能，您绝对不想管理自己的上传流。 （我们必须为大于2GB的文件上传编写我们自己的本机IIS 7处理程序。这是一个PITA。）您熟悉WCF中的并发和实例模型吗？ （如果没有，你可以从这里开始：http://msdn.microsoft.com/en-us/library/ms731193.aspx）我对此最熟悉，但我认为其他服务器框架具有类似的配置。我可以看到缓存列表数据的一些优势，以便在该场景中为您节省潜在的磁盘损失。在我工作的其中一个项目中，我们缓存了NT Domain登录令牌。这最终成为一种痛苦和负担，完全没有必要。我认为用于管理会话和服务器端权限的现有框架就足够了。