{"id":858,"date":"2011-07-02T20:46:07","date_gmt":"2011-07-02T18:46:07","guid":{"rendered":"http:\/\/blog.m-ri.de\/?p=858"},"modified":"2011-07-02T19:59:17","modified_gmt":"2011-07-02T17:59:17","slug":"vs-tipps-tricks-wie-man-gezielt-einen-breakpoint-fur-einen-thread-setzen-kann","status":"publish","type":"post","link":"http:\/\/blog.m-ri.de\/index.php\/2011\/07\/02\/vs-tipps-tricks-wie-man-gezielt-einen-breakpoint-fur-einen-thread-setzen-kann\/","title":{"rendered":"VS-Tipps & Tricks: Wie man gezielt einen Breakpoint f\u00fcr einen Thread setzen kann"},"content":{"rendered":"

Wenn man eine Anwendung oder einen Dienst hat, der mit vielen Threads arbeitet, dann kann das Debuggen abenteuerlich werden. Besonders wenn viele Threads ein und die selbe Threadfunktion verwenden.
\nWas macht man nun wenn man einen Thread isoliert hat und dessen Verhalten weiter pr\u00fcfen m\u00f6chte? Single-Stepping ist nicht drin, denn der Breakpoint w\u00fcrde auch jeden anderen Thread anhalten, der diese Code-Position erreicht.<\/p>\n

Die nachfolgende Methode ist relativ einfach um gezielt einen Breakpoint f\u00fcr einen Thread zu setzen.
\nGehen wir mal davon aus, dass wir im Debugger einen Breakpoint haben und uns im Kontext des Threads befinden, den wir nun weiter verfolgen wollen.<\/p>\n

    \n
  1. Zuallererst ermitteln wir die Thread-Id<\/em>.
    \nDas geht elementar einfach \u00fcber die Pseudo-Debugger-Variable $TID<\/em>, die wir uns im Watch-Fenster, oder im Quick-View anzeigen lassen:
    \n\"\"<\/a><\/li>\n
  2. Als n\u00e4chstes modifizieren wir den Breakpoint so, dass er nur noch dann stoppt, wenn auch unser Thread diesen Breakpoint erreicht.
    \nDas erreichen wir \u00fcber die Breakpoint-Eigenschaft Condition (rechter Mausklick, \u00fcber das Kontextmen\u00fc):
    \n    \"\"<\/a>
    \nHier geben wir einfach als Bedingung an, das $TID (also die Thread-ID) identisch sein muss, zu der ID des Threads, den wir beobachten wollen.<\/li>\n
  3. Den Rest macht der Debugger f\u00fcr uns, wenn wir wieder den Go-Befehl (F5) geben:
    \n    \"\"<\/a><\/li>\n<\/ol>\n

    Auf diese Weise kann man auch mehrere Threads einfach beobachten.<\/p>\n

    Hinweis:
    \nDieses Verfahren \u00e4ndert das Laufzeitverhalten des Programmes, denn der Breakpoint wird immer intern ausgef\u00fchrt, egal welcher Thread diese Codestelle passiert. Nur ermittelt der Debugger dann die Bedingung\u00a0returniert und l\u00e4sst das Programm, dann weiterlaufen, wenn die Id nicht passt. Wird diese Codestelle sehr\u00a0oft passiert, dann kann\u00a0ist der Einfluss eines solchen Breakpoints nicht\u00a0 unerheblich.<\/p>\n

    Alternativ, kann man in solch einem Fall auch ein St\u00fcck Code einsetzen, der die aktuelle Thread-ID gegen eine statische Variable testet und einen DebugBreak <\/em>ausf\u00fchrt. Die statische Variable setzt man dann w\u00e4hrend der Debugsession auf die gw\u00fcnschte Thread-ID \u00fcber das Watch-Window oder den Quick-View<\/p>\n

    Weiterf\u00fchrende Infos zu Debugger-Pseudo-Variablen von Visual-Studio findet man hier:
    \n    http:\/\/msdn.microsoft.com\/en-us\/library\/ms164891.aspx<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    Wenn man eine Anwendung oder einen Dienst hat, der mit vielen Threads arbeitet, dann kann das Debuggen abenteuerlich werden. Besonders wenn viele Threads ein und die selbe Threadfunktion verwenden. Was macht man nun wenn man einen Thread isoliert hat und dessen Verhalten weiter pr\u00fcfen m\u00f6chte? Single-Stepping ist nicht drin, denn der Breakpoint w\u00fcrde auch jeden … \u201eVS-Tipps & Tricks: Wie man gezielt einen Breakpoint f\u00fcr einen Thread setzen kann\u201c <\/span>weiterlesen<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[30,11,3,27,172],"tags":[38,296,171,37],"class_list":["post-858","post","type-post","status-publish","format-standard","hentry","category-c","category-debugging","category-programmieren","category-vs2008","category-vs2010","tag-debuggen","tag-testen","tag-vs-2010","tag-vs-tippstricks"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/posts\/858","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/comments?post=858"}],"version-history":[{"count":1,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/posts\/858\/revisions"}],"predecessor-version":[{"id":873,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/posts\/858\/revisions\/873"}],"wp:attachment":[{"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/media?parent=858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/categories?post=858"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.m-ri.de\/index.php\/wp-json\/wp\/v2\/tags?post=858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}