none
Are WinAPI functions thread-safe or NO?

    Question

  • Hi,

    The question is: are WinAPI functions thread-safe or NO? I mean: can I call them from different threads without any synchronization such as critical sections or others?

    Functions such as TextOut, DrawText from gdi32.lib and user32.lib, OR others from others libraries.

    Sunday, March 13, 2011 5:30 AM

Answers

  • Vladimir Belov wrote:

    The question is: are WinAPI functions thread-safe or NO? I mean: can I  call them from different threads without any
    synchronization such as critical sections or others?

    Functions such as TextOut, DrawText from gdi32.lib and user32.lib, OR  others from others libraries.

    GDI functions are not thread-safe, and moreover, many are  thread-affine. Almost anything that takes an HWND and/or an HDC must be  called on the same thread where that HWND or HDC was created  (SendMessage, PostMessage and similar are notable exceptions). HBITMAPs,  HICONs and such could be passed between threads, but should be  manipulated by one thread at a time.

    Most other functions - those that don't deal with GDI or window  management - are indeed thread-safe.


    Igor Tandetnik

    • Proposed as answer by Nikita Leontiev Sunday, March 13, 2011 10:19 PM
    • Marked as answer by Rob Pan Monday, March 21, 2011 1:41 AM
    Sunday, March 13, 2011 3:44 PM

All replies

  • Yes, straight Win32 API is thread safe.  However, things like inter-thread SendMessage calls can be tricky though because they get processed by the receiving thread at times you wouldn't expect.
    Sunday, March 13, 2011 2:24 PM
  • Vladimir Belov wrote:

    The question is: are WinAPI functions thread-safe or NO? I mean: can I  call them from different threads without any
    synchronization such as critical sections or others?

    Functions such as TextOut, DrawText from gdi32.lib and user32.lib, OR  others from others libraries.

    GDI functions are not thread-safe, and moreover, many are  thread-affine. Almost anything that takes an HWND and/or an HDC must be  called on the same thread where that HWND or HDC was created  (SendMessage, PostMessage and similar are notable exceptions). HBITMAPs,  HICONs and such could be passed between threads, but should be  manipulated by one thread at a time.

    Most other functions - those that don't deal with GDI or window  management - are indeed thread-safe.


    Igor Tandetnik

    • Proposed as answer by Nikita Leontiev Sunday, March 13, 2011 10:19 PM
    • Marked as answer by Rob Pan Monday, March 21, 2011 1:41 AM
    Sunday, March 13, 2011 3:44 PM
  • Thanks Ted, I very glad that it is so.

    But somebody said me that sometimes if two threads try to output text at the same place of the window with TextOut, that may lead to unpredictable results. What can you say about this? Does it happen because of not thread safe TextOut function or something else?

     

    Sunday, March 13, 2011 3:48 PM
  • Oh, you answered before my post. I answered on Ted post.

    Most other functions - those that don't deal with GDI or window  management - are indeed thread-safe.

    Where I can get accurate information about what function is thread safe or no? There is no such information in MSDN!

    Sunday, March 13, 2011 3:54 PM
  • You should simply adopt the commonly accepted design pattern: use only one thread (the GUI thread) to manage all GDI output. Other threads can be launched to handle non-GDI work, and they should communicate with the GUI thread when the result of their work needs to be reflected on the desktop.

    Sunday, March 13, 2011 4:29 PM
  • You should simply adopt the commonly accepted design pattern: use only one thread (the GUI thread) to manage all GDI output. Other threads can be launched to handle non-GDI work, and they should communicate with the GUI thread when the result of their work needs to be reflected on the desktop.


    Ok. I understood. But nevertheless is there no information about each function in WinAPI about thread safe. I want to know for 100% that function that I wiil use(non GDI) will work fine in my multithreded application.

    Do you agree with me that:

    1) This information can be displayed with MSDN description of concrete function. Why Microsoft doesn't do so?

    2) If I don't know for 100% that concrete WinAPI-function thread safe or no, I must include synchronization code and that's why perfomance of my application would be essentially worse? Why there is no information for each WinAPI-function such as "checkbox" :) 1. thread safe 2. not thread safe?

    Monday, March 14, 2011 7:11 AM

  • Do you agree with me that:

    1) This information can be displayed with MSDN description of concrete function. Why Microsoft doesn't do so?

    2) If I don't know for 100% that concrete WinAPI-function thread safe or no, I must include synchronization code and that's why perfomance of my application would be essentially worse? Why there is no information for each WinAPI-function such as "checkbox" :) 1. thread safe 2. not thread safe?

    I agree with you that threading requirements should be documented, and I don't know why it isn't done better in general. MSDN is not the only offender; most of documentation you'll find anywhere skim over these sorts of issues. I don't really agree that each function should have a simple checkbox, because the answer is more complicated than that (see discussion). But a general set of rules for a set of APIs + exceptions for those APIs that differ from the set, yeah, I could live with that.

    Otherwise, form some "from horse's mouth" details on your question, try googling for "Thread affinity of user interface objects" on OldNewThing.

    Goran.

    Monday, March 14, 2011 10:08 AM
  • Vladimir Belov wrote:
    >
    >But somebody said me that sometimes if two threads try to output text
    >at the same place of the window with TextOut, that may lead to
    >unpredictable results. What can you say about this? Does it happen
    >because of not thread safe TextOut function or something else?
     
    All graphic calls should be made from a user interface thread.  Now, in
    fact, GDI has locking so that only one thread at a time actually gets into
    the display driver, so there is a certainly amount of serialization.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.
     

    Tim Roberts, DDK MVP Providenza & Boekelheide, Inc.
    Saturday, March 26, 2011 5:13 AM
  • What about non-GDI WinAPI functions? Do you agree with Igor Tandetnik that "Most other functions - those that don't deal with GDI or window  management - are indeed thread-safe."?

     

    Saturday, March 26, 2011 6:25 AM
  • "those that don't deal with GDI or window management - are indeed thread-safe."?"

    Define thread-safe. Your earlier mention of TextOut makes me think that you don't really understand what tread-safe means in this case.

    For example WriteFile is thread-safe. That means that if 2 threads call WriteFile (on the same file handle) the system will not corrupt itself, won't blue screen, won't corrupt the on disk file structures etc.

    That doesn't mean that the contents of the resulting file will make sense. That's because the order in which the WriteFile calls are executed is basically undefined. If you need some particular ordering then it's your job to ensure that.

    Same thing happens with GDI. You can call it from different threads but since drawing order matters in general, you have the same problem.

    Saturday, March 26, 2011 6:44 AM
  • > What about non-GDI WinAPI functions? Do you agree with Igor Tandetnik that "Most other functions - those that don't deal with GDI or window  management - are indeed thread-safe."?

    Yes. They are.
    Specially all file and I/O functions are completely threadsafe.
    This doesn't mean that serialization doesn't matter.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Saturday, March 26, 2011 10:06 AM
  • Vladimir Belov wrote:
    >
    >What about non-GDI WinAPI functions? Do you agree with Igor Tandetnik
    >that "Most other functions - those that don't deal with GDI or window
    >management - are indeed thread-safe."?
     
    I suspect you are asking this question without thinking about what the
    concept really means.
     
    The only way a function is NOT thread-safe is if it accesses some shared
    state information without considering how other threads might access that
    data.  Many API functions transition right away to a kernel driver, and
    kernel drivers have always been thread safe.  Driver programmers have
    always had to think about stimuli from multiple simultaneous sources.
     
    Many other API functions simply don't need to access shared state.
     
    In short, yes, I agree with Igor.  Note, however, that you need to define
    carefully what constitutes the Windows API.  STL in the C++ runtime
    library, for example, is not thread-safe.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.
     

    Tim Roberts, DDK MVP Providenza & Boekelheide, Inc.
    Sunday, March 27, 2011 8:34 PM