是否' ReaderWriterLock '锁定资源,代码或线程?



我正在开发一个asp.net webapi项目。控制器动作方法将检查本地文件并在本地文件过期时下载更新的文件。由于此操作可能同时被多个客户端请求,因此我担心会出现文件并发问题。

在我的downloadService类,我考虑使用ReaderWriterLock

问题1:我应该在哪里初始化ReaderWriterLock?我应该保留它作为私人会员吗?

private readonly ReaderWriterLock asyncReaderWriterLock = new();

或者我应该每次在fileWrite方法中创建它?

问题2:假设它是一个实例成员,如果有多个downloadService对象,那么就会有很多锁。它还能起作用吗?

是锁文件还是锁代码?

问题3:如果有100个文件,当我操作文件A时,它不应该影响文件B,这意味着线程B可以在线程A写文件A的同时写文件B,所以我需要为这些文件分配100个锁吗?

感谢

我应该在哪里初始化ReaderWriterLock?

你应该在使用它的类中初始化它

我应该保留它作为私有成员吗?

是的,否则可能会有一些不相关的类占用锁,这会增加死锁的风险。避免死锁的一个好做法是只锁定一小段代码,并且在持有锁的同时避免引发任何事件或调用任意代码。

或者我应该每次在fileWrite方法中创建它?

锁对象应该表示被锁定的资源,并且每个资源应该只有一个锁对象。为每个fileWrite创建一个新对象会适得其反,因为它不会提供任何保护。

假设它是一个实例成员,如果有多个downloadService对象,那么就会有很多锁。它还能起作用吗?

是的,你可以有任意多的锁对象。

这个锁文件还是代码?

锁对象不关心被保护的是什么。它只是确保一次只有一个线程可以持有锁。保护什么由你决定。

如果有100个文件,当我操作文件A时,它不应该影响文件B,这意味着线程B可以在线程A写文件A的同时写文件B,所以我需要为这些文件分配100个锁吗?

如果你想要在文件级别的锁粒度,那么你需要每个文件一个锁。

我要指出多线程编程是困难的。线程错误往往是虚假的,难以重现和不明显。当涉及多个线程时,一些关于排序的规则就不适用了。所以我鼓励你在做任何涉及多线程的重要事情之前,多阅读一些关于这个主题和所涉及的危险的内容。

最新更新