CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 16
  1. #1
    Join Date
    Dec 2014
    Posts
    13

    WinAPI timer vs thread?

    I am creating a WinAPI application, and I want to use a timer. Should I use the WinAPI timer mechanism (SetTimer(), etc.), or should I create a new thread (with a Sleep(timeout) inside of it)?

  2. #2
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: WinAPI timer vs thread?

    It all depends on the task you are going to work on.
    On many cases a simple timer would be more than enough. In some others a worker thread (or threads) would needed. Sometimes a WaitableTimer would be the best solution...
    Victor Nijegorodov

  3. #3
    Join Date
    Dec 2014
    Posts
    13

    Re: WinAPI timer vs thread?

    Quote Originally Posted by VictorN View Post
    It all depends on the task you are going to work on.
    On many cases a simple timer would be more than enough. In some others a worker thread (or threads) would needed. Sometimes a WaitableTimer would be the best solution...
    It it okay to manipulate the GUI controls inside of a worker thread (because I've heard that in order to do that I have to create a WinAPI timer)?

  4. #4
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: WinAPI timer vs thread?

    Quote Originally Posted by joseph_w View Post
    It it okay to manipulate the GUI controls inside of a worker thread (because I've heard that in order to do that I have to create a WinAPI timer)?
    No. It is a wrong way. Only the thread to which these controls belong may manipulate them.
    The worker threads should only inform the main GUI thread (using PostMessage or some other means) that something has changed, and, perhaps, supply some new data to it in order to let change something in UI.
    Victor Nijegorodov

  5. #5
    2kaud's Avatar
    2kaud is online now Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: WinAPI timer vs thread?

    One thread should handle the gui controls, other threads do processing and post messages as required to the gui thread to update the controls.

    PS There have been previous discussions on these forums re worker threads and gui controls. A forum search should be able to locate them.
    Last edited by 2kaud; December 14th, 2014 at 08:57 AM. Reason: Added PS
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

  6. #6
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: WinAPI timer vs thread?

    Timer vs. thread depends on the work you need to do. If the work is time sensitive (i.e you are polling some hardware and need to poll within a certain interval otherwise you risk losing data), then a worker thread is probably the way to go.

    The reason for this is that a timer in the main thread shares the message system along with everything else. What this means is that UI operations can prevent the timer from firing. So if the system is busy processing mouse, repaint or window position messages, timers messages may not get processed.

    On the other hand, a worker thread is off running on it's own and is independent of what the UI thread is doing. So a worker thread is often a better choice for doing time sensitive data retrieval or processing.

    When I need to control the start, stop, pause and resume of an operation, for me it's actually easier to spin up a worker thread and supply a couple of events that signal the thread to stop, pause and resume.

    I know some folks feel it's simpler to do this in the main UI thread, but I find for this level of control is easier to do in a worker thread. Doing this in the main UI thread requires that you perform frequent checks, pump messages throughout the 'worker' operation, have additional flags variables, and so on. Frequently the code ends up being more complicated when done in the main thread.

    You can tell I'm not a big fan of performing worker operations in the main thread.... another reason for not doing this is to consider it from the separation of concerns/single responsibility point of view - with this mindset, worker operation code doesn't belong in the UI layer anyway.

  7. #7
    Join Date
    Dec 2014
    Posts
    13

    Re: WinAPI timer vs thread?

    Quote Originally Posted by VictorN View Post
    No. It is a wrong way. Only the thread to which these controls belong may manipulate them.
    The worker threads should only inform the main GUI thread (using PostMessage or some other means) that something has changed, and, perhaps, supply some new data to it in order to let change something in UI.
    But what is the problem in doing something like that from a worker thread:

    Code:
    SendMessage(hWindow, WM_SETTEXT, 0, (LPARAM)"Hello World");
    Wouldn't the message just get added to the UI thread message queue?

  8. #8
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: WinAPI timer vs thread?

    You must be cautious when doing with SendMessage having possible deadlocks in mind (not in the case you showed), but in case you are, there would be no problem except one point: your GUI logic is gonna be spread across the threads and eventually tend to be out of control.
    Best regards,
    Igor

  9. #9
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: WinAPI timer vs thread?

    Quote Originally Posted by joseph_w View Post
    But what is the problem in doing something like that from a worker thread:

    Code:
    SendMessage(hWindow, WM_SETTEXT, 0, (LPARAM)"Hello World");
    Wouldn't the message just get added to the UI thread message queue?
    No, it will call the window procedure. And could cause the deadlocking. See the Multiple Threads in the User Interface, particulary the section How to avoid message deadlocking
    Victor Nijegorodov

  10. #10
    Join Date
    Dec 2014
    Posts
    13

    Re: WinAPI timer vs thread?

    Quote Originally Posted by VictorN View Post
    No, it will call the window procedure. And could cause the deadlocking. See the Multiple Threads in the User Interface, particulary the section How to avoid message deadlocking
    I thought that if SendMessage() is called from the UI thread will call the window procedure directly, however if called from another thread it will put the message into the UI thread message queue.

  11. #11
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: WinAPI timer vs thread?

    Quote Originally Posted by joseph_w View Post
    I thought that if SendMessage() is called from the UI thread will call the window procedure directly, however if called from another thread it will put the message into the UI thread message queue.
    SendMessage will put a message in the queue of the window specified by hWnd - which may or may not be the queue for the main UI thread.

    At any rate, SendMessage usually isn't the method to call from the worker thread. The reason being is it's synchronous method call, so you block the worker thread until the UI thread processes the message. As I mentioned in my previous posts, if the UI thread is busy processing other messages, it may be a while before it processes the SendMessage call from the worker thread. If the UI thread is hung, it won't process the SendMessage msg and will hang your worker thread.

    Victor specifically mention using PostMessage (not SendMessage) for this very reason.

  12. #12
    Join Date
    Dec 2014
    Posts
    13

    Re: WinAPI timer vs thread?

    Quote Originally Posted by Arjay View Post
    SendMessage will put a message in the queue of the window specified by hWnd - which may or may not be the queue for the main UI thread.

    At any rate, SendMessage usually isn't the method to call from the worker thread. The reason being is it's synchronous method call, so you block the worker thread until the UI thread processes the message. As I mentioned in my previous posts, if the UI thread is busy processing other messages, it may be a while before it processes the SendMessage call from the worker thread. If the UI thread is hung, it won't process the SendMessage msg and will hang your worker thread.

    Victor specifically mention using PostMessage (not SendMessage) for this very reason.
    But if I created all of the controls in the UI thread, won't all of the messages sent to these controls be added to this UI thread message queue? Does each control has it's own message queue?!

  13. #13
    2kaud's Avatar
    2kaud is online now Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: WinAPI timer vs thread?

    The way this is usually done is that worker threads post user-defined messages to the ui thread (normally the main thread) and the ui thread processes these messages when it can as appropriate - which may involve sending messages to controls. But the point here is that only the ui thread interacts with the controls. All other threads post to the ui thread so are not blocked by the ui thread - and the ui thread is not waiting for worker threads.

    See http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx for more info re message queues and sending and posting messages.
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

  14. #14
    Join Date
    Dec 2014
    Posts
    13

    Re: WinAPI timer vs thread?

    The conclusion that I have reached is that there is no harm in manipulating the UI controls from a worker thread, but from a design perspective (and to prevent deadlocks) it is a better idea to only make the UI thread responsible for manipulating the UI controls.

  15. #15
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: WinAPI timer vs thread?

    Quote Originally Posted by joseph_w View Post
    I thought that if SendMessage() is called from the UI thread will call the window procedure directly, however if called from another thread it will put the message into the UI thread message queue.
    Both times it results in window procedure direct calling. The difference is that when calling from worker thread, the caller thread gets blocked, the context is switched to UI thread, the window procedure is called, and when the call finishes, the caller thread gets unblocked. No putting message onto message queue occurs.

    The fact of blocking caller thread creates the danger of deadlocking: in case the call tries to obtain some synchronization object, and the object is currently owned by the blocked thread, the call has no chance to return.
    Last edited by Igor Vartanov; December 16th, 2014 at 06:50 AM.
    Best regards,
    Igor

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured