{"id":9933,"date":"2011-08-10T07:00:00","date_gmt":"2011-08-10T07:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2011\/08\/10\/slim-readerwriter-locks-dont-remember-who-the-owners-are-so-youll-have-to-find-them-some-other-way\/"},"modified":"2011-08-10T07:00:00","modified_gmt":"2011-08-10T07:00:00","slug":"slim-readerwriter-locks-dont-remember-who-the-owners-are-so-youll-have-to-find-them-some-other-way","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20110810-00\/?p=9933\/","title":{"rendered":"Slim reader\/writer locks don't remember who the owners are, so you'll have to find them some other way"},"content":{"rendered":"

\nThe\n\nslim reader\/writer lock<\/a>\nis a very convenient synchronization facility,\nbut one of the downsides is that it doesn’t keep track of who\nthe current owners are.\nWhen your thread is stuck waiting to acquire a slim\nreader\/writer lock,\na natural thing to want to know is which threads own the resource\nyour stuck thread waiting for.\n<\/p>\n

\nSince there’s not facility for going from the waiting thread\nto the owning threads,\nyou’ll just have to find the owning threads some other way.\nHere’s the thread that is waiting for the lock in shared mode:\n<\/p>\n

\nntdll!ZwWaitForKeyedEvent+0xc\nntdll!RtlAcquireSRWLockShared+0x126\ndbquery!CSearchSpace::Validate+0x10b\ndbquery!CSearchSpace::DecomposeSearchSpace+0x3c\ndbquery!CQuery::AddConfigs+0xdc\ndbquery!CQuery::ResolveProviders+0x89\ndbquery!CResults::CreateProviders+0x85\ndbquery!CResults::GetProviders+0x61\ndbquery!CResults::CreateResults+0x11c\n<\/pre>\n
\nOkay, how do you find the thread that owns the lock?\n<\/p>\n
\nFirst, slim reader\/writer locks are usable only within a process,\nso the candidate threads are the one within the process.\n<\/p>\n
\nSecond, the usage pattern for locks is nearly always something like\n<\/p>\n
\n    enter lock\n    do something\n    exit lock\n<\/pre>\n
\nIt is highly unusual for a function to take a lock and exit to\nexternal code with the lock held.\n(It might exit to other code within the same component,\ntransferring the obligation to exit the lock to that other code.)\nTherefore, you want to look for threads that are still inside\ndbquery.dll<\/code>,\npossibly even still inside\nCSearch­Space<\/code> (if the lock is a per-object lock\nrather than a global one).\n<\/p>\n
\nOf course, the possibility might be that the code that entered\nthe lock messed up and forgot to release it,\nbut if that’s the case,\nno amount of searching for it will find anything since the culprit\nis long gone.\nSince\n\ndebugging is an exercise in optimism<\/a>,\nwe may as well proceed on the assumption that we’re not in the case.\nIf it fails to find the lock owner, then we may have to revisit\nthe assumption.\n<\/p>\n
\nFinally, the last trick is knowing\n\nwhich threads to ignore<\/a>.\nFor now, you can also ignore the threads that are waiting for the lock,\nsince they are the victims not the cause.\n(Again, if we fail to find the lock owner, we can revisit the assumption\nthat they are not the cause; for example, they may be attempting to acquire\nthe lock recursively.)\n<\/p>\n
\nAs it happens,\nthere is only one thread in the process that passes all the above filters.\n<\/p>\n
\ndbquery!CProp::Marshall+0x3b\ndbquery!CRequest::CRequest+0x24c\ndbquery!CQuery::Execute+0x668\ndbquery!CResults::FillParams+0x1c4\ndbquery!CResults::AddProvider+0x4e\ndbquery!CResults::AddConfigs+0x1c5\ndbquery!CResults::CreateResults+0x145\n<\/pre>\n
\nThis may not be the source of the problem, but it’s a good start.\n(Actually, it looks very promising since the problem is probably\nthat the process on the other side of the marshaller is stuck.)<\/p>\n","protected":false},"excerpt":{"rendered":"
The slim reader\/writer lock is a very convenient synchronization facility, but one of the downsides is that it doesn’t keep track of who the current owners are. When your thread is stuck waiting to acquire a slim reader\/writer lock, a natural thing to want to know is which threads own the resource your stuck thread […]<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-9933","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
The slim reader\/writer lock is a very convenient synchronization facility, but one of the downsides is that it doesn’t keep track of who the current owners are. When your thread is stuck waiting to acquire a slim reader\/writer lock, a natural thing to want to know is which threads own the resource your stuck thread […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/9933","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=9933"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/9933\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=9933"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=9933"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=9933"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}