所以我试图通过共享资源来解决线程问题。 c#corner(链接1)和msdn(链接2)上的示例提供了基本语法示例和一些理论框架,因此锁定共享资源的基本前提是我理解的进程。现在,我的问题是:
当访问和操作同一代码块中的多个共享资源时(在从共享堆栈弹出URL的循环爬虫进程下面的“伪代码”中,将当前url评估为已检查URL的共享列表,然后将下载的数据推送到另一个共享堆栈),是否需要在锁定语句中包含与特定共享资源相关的每个代码段?
c#中的“lock(this){}”结构在后台实现“Monitor”(链接3),而Monitor.Enter和Monitor.Exit都只将一个对象作为参数。< / p>
诚实地说,我还没有对此进行编码并对其进行测试。但是当我正在阅读时,我想知道这一点,之后我正在布局代码的结构(下面的“伪代码”)。我将锁定结构的起点和终点大写,如果我的假设是正确的,我怀疑它们是正确的。
任何可以为我澄清/验证这一点的人?
(由于我没有获得必要的声望分数,我发布了这样的链接,你可以在底部找到它们; @mods:如果我违反任何这样做,请告诉我,我将修改帖子。 )
program starts;
stack (urlsToCheck) is created (static, String);
list (checkedUrls) is created (static, String);
stack (unparsedHTML) is created (static, Tuple(string, Byte[]);
user provides seed url;
seed url is pushed to top op stack (urlsTocheck);
thread is created for Crawler method GetData();
<!--research possibilities for multiple threads in relation to stack sizes-->
<!--in case of multiple threads : threadpool + object (crawler) array?-->
thread is started:
Crawler 1 is created;
Crawler 1 starts method GetData:
loop:
<!--//check loop for lock/unlock locations//-->
Crawler 1 evaluates size of stack (unparsedHTML):
if(size > 100):
wait 1000 ms;
Crawler 1 evaluates size of stack (unparsedHTML);
else:
continue;
LOCK;
Crawler 1 evaluates size of stack (urlsToCheck):
if(size > 0):
Crawler 1 pops url from stack (urlsToCheck);
continue;
else:
wait 1000 ms;
Crawler 1 evaluates size of stack (urlsToCheck);
Crawler 1 evaluates url for membership in List (checkedUrls):
if(membership):
discard url;
pop url from stack (urlsToCheck);
evaluate url for membership in List (checkedUrls);
else:
continue;
UNLOCK;
LOCK;
Crawler 1 downloads data from url;
Crawler makes tuple of url and data;
Crawler pushes tuple onto stack (unparsedHTML);
UNLOCK;
end loop;
1)http:// www.c-sharpcorner.com/UploadFile/mgold/MultithreadingIntro10062005000439AM/MultithreadingIntro.aspx
2)https:// msdn.microsoft.com/en-us/library/aa645740(v = vs.71).aspx
3)https:// msdn.microsoft.com/en-us/library/hf5de04k%28v=vs.110%29.aspx
答案 0 :(得分:0)
我的意见是,是的,您希望在单独的锁中包含与特定共享资源相关的每个段(类似于您上面的内容)。一个主要原因是这有助于最小化任何给定线程保留在资源上的时间。我还发现它有助于防止线程持有锁的情况,但是试图获得另一个可以快速挂起程序的锁。这只是因为您的锁定部分通常较短,并且在代码中更容易发现此问题。它不是万无一失,但有帮助。
显然,发布和获取锁会涉及成本,因此时间或资源敏感的环境需要在频繁发布和获取锁的成本与等待锁的成本之间找到适当的平衡。在您的示例中,这意味着如果您只对整个代码块进行一次锁定,程序运行得更快,或者如果您坚持使用当前的释放方案并在移动到新共享时获得新锁定,则运行得更快资源?根据我的经验,后者更好。
我所说的内容有各种各样的警告和例外,当你实际实现代码时,你可能会发现自己的一些,但你目前关于如何锁定的想法是我的方式继续。