WaitForSingleObject<\/CODE><\/a>.\nThey typically treat this as a successful wait,\nbecause it does mean that the object was obtained,\nbut it also tells you that the previous owner left the\nmutex abandoned and that the system had to release it on\nthe owner’s behalf.\n<\/P>\n\nWhy are you in big trouble when this happens?\n<\/P>\n
\nPresumably, you created that mutex to protect multiple threads\nfrom accessing a shared object while it is an unstable state.\nCode enters the mutex, then starts manipulating the object,\ntemporarily making it unstable, but eventually restabilizing\nit and then releasing the mutex so that the next person can access\nthe object.\n<\/P>\n
\nFor example, you might have code that manages an\nanchored doubly-linked list\nin shared memory that goes like this:\n<\/P>\n
\nvoid MyClass::ReverseList()\n{\n WaitForSingleObject(hMutex, INFINITE);\n int i = 0; \/\/ anchor\n do {\n int next = m_items[i].m_next;\n m_items[i].m_next = m_items[i].m_prev;\n m_items[i].m_prev = next;\n i = next;\n } while (i != 0);\n ReleaseMutex(hMutex);\n}\n<\/PRE>\n\nThere is nothing particularly exciting going on.\nBasic stuff, right?\n<\/P>\n
\nBut what if the program crashes while holding the mutex?\n(If you believe that your programs are bug-free,\nconsider the possiblity that the program is running\nover the network and the network goes down, leading\nto an in-page exception.\nOr simply that the user went to Task Manager\nand terminated your program while this function is running.)\n<\/P>\n
\nIn that case, the mutex is automatically released\nby the operating system,\nleaving the linked list in a corrupted state.\nThe next program to claim\nthe mutex will receive WAIT_ABANDONED<\/CODE> as the\nstatus code.\nIf you ignore that status code,\nyou end up operating on a corrupted linked list.\nDepending on how that linked list is used, it may\nresult in a resource leak or the system creating an\nunintended second copy of something, or perhaps even a crash.\nThe unfortunate demise of one program causes other programs\nto start behaving strangely.\n<\/P>\n\nThen again, the question remains,\n“What do you do, then, if you get WAIT_ABANDONED<\/CODE>?”\nThe answer is, “Good question.”\n<\/P>\n\nYou might try to repair the corruption, if you keep enough\nauxiliary information around to recover a consistent state.\nYou might even design your data structures to be transactional,\nso that the death of a thread manipulating the data structures\ndoes not leave them in a corrupted state.\nOr you might just decide that since things are corrupted,\nyou should throw away everything and start over,\nlosing the state of work in progress, but at least allowing\nnew work to proceed unhindered.\n<\/P>\n
\nOr you might simply choose to ignore the error and continue\nonwards with a corrupt data structure, hoping that whatever\nwent wrong won’t result in cascade failures down the line.\nThis is what most people do, though usually without even being\naware that they’re doing it.\nAnd it’s really hard to debug the crashes that result from this\napproach.\n<\/P>\n
\nExercise<\/STRONG>:\nWhy did we use indices instead of pointers in our\nlinked list data structure?\n<\/P>\n\n[Raymond is currently away; this message was pre-recorded.]\n<\/P><\/p>\n","protected":false},"excerpt":{"rendered":"
One of the important distinctions between mutexes and the other synchronization objects is that mutexes have owners. If the thread that owns a mutex exits without releasing the mutex, the mutex is automatically released on the thread’s behalf. But if this happens, you’re in big trouble. One thing many people gloss over is the WAIT_ABANDONED […]<\/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":[25],"class_list":["post-34253","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
One of the important distinctions between mutexes and the other synchronization objects is that mutexes have owners. If the thread that owns a mutex exits without releasing the mutex, the mutex is automatically released on the thread’s behalf. But if this happens, you’re in big trouble. One thing many people gloss over is the WAIT_ABANDONED […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/34253","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=34253"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/34253\/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=34253"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=34253"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=34253"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}