Question on using multithreading to periodically and forcefully check for updates on software

I'm working on an application that has a main thread performing some work (message loop of the UI etc.), but I would also like a second thread, which would periodically test if there are any updates available to download. I would also like the possibility for the main thread to ask the secondary thread to force checking for updates, and for the secondary thread to ask the main thread for confirmation on downloading updates.

I don't have that much experience with IPC and multithreading in real life situations, so I'm not sure how I should go about designing this. I would like to eventually have this work on both Windows and POSIX, but let us focus on POSIX for now. Here's my idea so far:

Secondary thread pseudocode:

repeat forever:
  check_for_updates()

  if (are_any_updates()) {
    put the list of available updates on some message queue
    send signal SIGUSER1 to main thread
    wait for response from that message queue
    if (response is positive) download_updates()
  }
  unblock signal SIGUSER1 on secondary thread
  Sleep(one hour)
  block signal SIGUSER1
  if (any_signal_was_received_while_sleeping)
   any_signal_was_received_while_sleeping := false
   Sleep(one more hour)

SIGUSER1 handler on secondary thread (main thread has requested us to check for updates):

  block signal SIGUSER1 (making sure we don't get signal i开发者_StackOverflow社区n signal)
  any_signal_was_received_while_sleeping := true
  check_for_updates()
  ...
  unblock signal SIGUSER1

Basically, main thread uses SIGUSER1 to ask the secondary thread to force checking for updates, while secondary thread uses SIGUSER1 to ask the main thread to look into the message queue for the available updates and to confirm whether they should be downloaded or not.

I'm not sure if this is a good design or if it would even work properly. One of my problems is related to handling SIGUSER1 received in the main thread, because it's a pretty big application and I'm not really sure when is the right time to block and unblock it (I assume it should be somewhere in the message loop).

Any opinion is appreciated, including advice on what IPC features should I use on Windows (maybe RPC instead of signals?). I could completely remove the use of message queue if I settled on threads, but I might consider using processes instead. I'll clearly use threads on Windows, but I'm not sure about POSIX yet.

---

You should strongly consider using boost::thread to solve your problem. It is far more comprehensible than directly using posix and is cross platform. Take the time to use a better tool and you will end up saving yourself a great deal of effort.

In particular I think you will find that a condition variable would neatly facilitate your simple interaction.

EDIT:
You can do almost anything with the correct use of mutexes and condition variables. Another piece of advice would be to encapsulate your threads inside class objects. This allows you to write functions that act on the thread and it's data. In your case the main thread could have a method like requestUpdateConfirmation(), inside this you can block the calling thread and wait for the main thread to deal with the request before releasing the caller.