Thread affinity of user interface objects, part 4: GDI objects and other notes on affinity

Date:October 13, 2005 / year-entry #304
Tags:code
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20051013-11/?p=33783
Comments:    4
Summary:GDI objects are much simpler. As a general rule, they all have process affinity: They can be used by any thread in the process that created them. If you use a GDI object from multiple threads, it is your responsibility to coordinate the object's use. Note that the window manager and GDI as a general...

GDI objects are much simpler. As a general rule, they all have process affinity: They can be used by any thread in the process that created them. If you use a GDI object from multiple threads, it is your responsibility to coordinate the object's use.

Note that the window manager and GDI as a general rule keep their respective objects thread-safe. When I say that it is your responsibility to coordinate an object's use from multiple threads, I mean that you have to coordinate among your own threads if you're going to modify the object from one thread and read from it on another or modify it from two threads. For example, if one thread enumerates a menu while another is modifying it, the one doing the enumeration will get inconsistent results. Similarly, if two threads both try to change a menu item at the same time, the last writer will win.

Next time, we wrap up with a discussion of clean-up.


Comments (4)
  1. mschaef says:

    I apologize if this is out of scope for blog comments on this post, but it seems related to thread affinity.

    Can HFONT’s be selected into more than one DC at a time? Or, is it essential to have a seperate HFONT for each DC?

  2. mschaef says:

    "related to thread affinity"

    Related in the sense of: "Must I enforce this constraint if multiple threads are using my HFONT? Or more generally, must I enforce this constraint at all?"

  3. Mike says:

    I don’t know about fonts, but I do know you need to either synchronize else duplicate (application-resource) bitmaps. I had a multithreaded MDI (test-) app that used the same bitmap in two different MDIChild windows running in separate threads. While it worked as expected on a uni-CPU machine it flickered madly on a dual box (read: it was a complete disaster).

    So if bitmaps can only be selected into a single DC (even if only for read-access, and even if the DC’s are 100% compatible – no difference in resolution, color-depth or anything), I see no obvious reason to expect fonts should be any better – except they aren’t usually application-resources, but system resources, so maybe the system serializes access to them (or even allows concurrent access).

  4. sandman says:

    Thanks , for these interesting comments on thread and

    process affinity.

    Having struggled without this informaion in the past, is there any chance that this information will get into the msdn documentation. At least in term of the defining the affinity scope of the objects and illegal behaviours.

    Thanks

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index