• The Old New Thing

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


    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.

  • The Old New Thing

    Newark Liberty International Airport Terminal A travel tips


    The line for going through the security checkpoint at Terminal A of Newark Liberty International Airport splits into three lines after you get through the ID check. When you get to the decision point, they all look the same, but don't be fooled.

                 ID  / 3 ----------------------------------X
    >>>-----------|--  2 ------------------------X
               check \ 1 -------------X

    Take line 1. As you can see, it is a much shorter wait than the others.

    If you observe carefully as you get into line, you'll see that all the people in business suits are in line 1. That's because the business travelers know this secret and the tourists don't.

    The lines are uneven due to space constraints. In reality, the corridor looks more like this:

                 ID  / 3 -----------------------------------XXXXXXXXX---
    >>>-----------|--  2 ------------------------XXXXXXXXX  XXXXXXXXX 
               check \ 1 -------------XXXXXXXXX  XXXXXXXXX--------------

    (I still call it Newark International Airport, since that's the name it had when I lived in New Jersey.)

  • The Old New Thing

    Thread affinity of user interface objects, part 3: Menus, icons, cursors, and accelerator tables


    The remaining user interface objects in common use are menus, icons, cursors, and accelerator tables.

    Menus do not have thread affinity. Any thread can use a menu. However, if two threads use a menu, it is the responsibility of those threads to coordinate among themselves how that menu will be used, so that one thread doesn't modify a menu while another is busy displaying it, for example. (More on this subject later.)

    Icons, cursors, and accelerator tables behave like menus. They do not have thread affinity. They are easier to manage than menus since they cannot be modified once created, so the only thing you have to worry about is not to use one after it has been destroyed.

    Next time, GDI objects and an expansion on the subject of thread safety.

  • The Old New Thing

    New blog on integrating Groove with Office


    Andrew Wharton from Groove has started writing about integrating the team and its product with Office. His opening salvo sets the stage and hooked me in for what looks to be an interesting glimpse into life in another division at Microsoft. (Something that is as mysterious to me as it is to you.)

    In the early days of the Windows division, there was friction among the groups that were thrown together to form the project, because when your group is told to join forces with another group, your natural tendency is to treat the other group as "them". And of course "they" are dumber, slower, and less physically attractive than you are. That's why they're "they" and you're "us". "We" always make the right decisions and "they" always make the wrong ones.

    To remedy this situation, the powers that be established regular "Windows Integration Meetings" (also known as "WIMs"), wherein the disparate and mutually distrustful groups would get together and work out their differences. The medium for this process was, of course, beer and snacks.

    The "meetings" were a success. The groups began seeing each other as members of a team rather than adversaries. As the Windows division grew, these "Integration Meetings" welcomed new groups to the project and continued to serve their purpose of smoothing tensions among them.

    At some point, the "I" in "WIM" began to stand for "Informational" rather than "Integration", but that had no practical effect since people still call it the "WIM". Regardless of what the letter officially stands for, the "I" stands for "beer".

  • The Old New Thing

    Thread affinity of user interface objects, part 2: Device contexts


    Last time, we discussed briefly the thread affinity rules that govern window handles.

    Device contexts (DCs) also have a certain degree of thread affinity. The thread that calls functions such as GetDC must also be the one that calls ReleaseDC, but as with window handles, during the lifetime of the DC, any thread can use it. If you choose to use a DC in a multi-threaded manner, it's your responsibility to coordinate the consumers of that device context so that only one thread uses it at a time. For example, to host windowless controls across multiple threads, the host obtains a DC on the host thread, then asks each control in sequence to draw itself into that DC. Only one control draws into the DC at a time, even if the control happens to be on a different thread.

    The thread affinity of DCs is much more subtle than that of window handles, because if you mess up and release a DC from the wrong thread, things will still seem to be running okay, but the window manager's internal bookkeeping will be messed up and you may get a bad DC from GetDC a little later down the line.

    Next time, the remaining user interface elements.

  • The Old New Thing

    The difficult balancing act between customization and supportability


    My colleague Kam VedBrat (from who I shamelessly stole the pictures of thse high-DPI displays in my PDC talk) discusses the difficult balancing act between customization and supportability. (Part II.) Note that decisions on this subject also also impact compatibility: Windows Vista greatly expands the palette of objects covered by the visual style. Any visual styles designed for Windows XP need to be revised in order to cover those new Windows Vista elements. Whose reponsibility would it be to revise them?

  • The Old New Thing

    Thread affinity of user interface objects, part 1: Window handles


    Different objects have different thread affinity rules, but the underlying principles come from 16-bit Windows.

    The most important user interface element is of course the window. Window objects have thread affinity. The thread that creates a window is the one with which the window has an inseparable relationship. Informally, one says that the thread "owns" the window. Messages are dispatched to a window procedure only on the thread that owns it, and generally speaking, modifications to a window should be made only from the thread that owns it. Although the window manager permits any thread to access such things as window properties, styles, and other attributes such as the window procedure, and such accesses are thread safe from the window manager's point of view, load-modify-write sequences should typically be restricted to the owner thread. Otherwise you run into race conditions such as the following:

    wpOld = (WNDPROC)GetWindowLongPtr(hwnd, GWLP_WNDPROC);
    SetWindowLongPtr(hwnd, GWLP_WNDPROC, (LONG_PTR)newWndProc);
    LRESULT CALLBACK newWndProc(...)
     ... CallWindowProc(wpOld, ...); ...

    If modifications to the window procedure are made carelessly from any thread, then between the first two lines, a second thread may change the window procedure of the window, resulting in newWndProc passing the wrong "previous" window procedure to CallWindowProc.

    Why, then, does Windows even allow a non-owner thread from changing the window procedure in the first place? Because, as we all know, 16-bit Windows was a co-operatively multi-tasked system, which means that one thread could do anything it wanted secure in the knowledge that no other thread would interrupt it until it explicitly relinquished control of the CPU. Therefore, the above code sequence was safe in 16-bit Windows. And for compatibility reasons, the code continues to be legal, even though it isn't safe any more. (Note, however, that in an attempt to limit the scope of the damage, the window manager allows only threads in the process that owns the window to change the window procedure. This is a reasonable limitation since separate address spaces mean that function addresses in other processes are meaningless in the process that owns the window anyway.)

    Next time, a look at device contexts.

  • The Old New Thing

    On the dangers of sharing your apartment


    My colleague Marc Miller wrote up a brief essay on the subject of dealing with a neutral apartment that has been injected into your single-threaded apartment: COMmunism: Sharing your Apartment. Highly recommended.

  • The Old New Thing

    Your profiling tools can manufacture performance issues where there were none


    When analyzing the performance of a program, you must be mindful that your performance analysis tools can themselves affect the operation of the system you are analyzing. This is especially true if the performance analysis tool is running on the same computer as the program being studied.

    People often complain that Explorer takes a page fault every two seconds even when doing nothing. They determine this by opening Task Manager and enabling the Page Faults column, and observing that the number of Page Faults increases by one every two seconds.

    This got reported so often that I was asked to sit down and figure out what's going on.

    Notice, though, that if you change Task Manager's Update Speed to High, then Explorer's page fault rate goes up to four per second. If you drop it to Low, then it drops to one every four seconds.

    If you haven't figured it out by now, the reason is that Task Manager itself is causing those page faults. Mind you, they are soft faults and therefore do not entail any disk access. Every two seconds (at the Normal update rate), Task Manager updates the CPU meter in the taskbar, and it is this act of updating the CPU meter that is the cause of the page faults.

    No Task Manager, no animating taskbar notification icon, and therefore no page faults from Explorer when idle.

    (A similar effect was discovered by Mark Russinovich when he found that Process Explorer's polling calls to the EnumServiceStatusEx function was triggering repeated registry access.)

  • The Old New Thing

    Jensen Harris joins the 7am club


    My colleague Jensen Harris from the Office User Interface team has joined the 7am club, posting fascinating glimpes into Office history and the upcoming version of Office code-named "Office 12". And they come out at 7am every weekday.

    Then again, maybe he's not real either. Maybe he's some kind of a robot.

Page 372 of 464 (4,635 items) «370371372373374»