Hi fmatthew!   
      
   On Friday, September 21, 2012 12:23:36 AM UTC-4, fmatthew5876 wrote:   
   > I have a game engine where I want to queue asynchronous IO requests   
   > and poll every frame until they are all finished. This is using C++   
   > std::thread and friends.   
      
   Before answering you specific question, I would comment that I would   
   try to avoid polling.   
      
   > Basically the work flow of the main thread is like this   
   >   
   > 1. queue io requests   
   > 2. check if done == false   
   > 3. check if done == false   
   > ....   
   > n. check if done == true; flush()   
      
   When you have a multi-threaded program and find yourself polling, it's   
   generally a sign that you can do things in a more "thread-centric"   
   way.  I would suggest:   
      
       1. queue io requests   
       2. wait on a condition variable   
         [ thread(s) that process the io requests signal the cv ]   
       3. [ awake when cv signalled ] flush();   
      
   (Of course, if you don't control the code that processes the io   
   requests, you may have to poll, but if you do, you just need change   
   something like "done = true;" to something like "cv.notify_one();".)   
      
   > Then the game runs for a long time until its ready to load the next   
   > set of game resources.   
   >   
   > After calling flush(), all of the IO resources are loaded and   
   > synchronization is complete. My question now is what to do with the   
   > IO thread.   
   >   
   > One option is to let it exit and join() it. Then later when I want   
   > to queue up a new set of IO's I have to recreate the thread.   
      
   Yes, but as you ask, why?   
      
   > The other option is to let it block on a condition variable   
   > indefinatly until a new IO request is given.   
      
   This seems exactly right to me, and is a standard sort of "producer /   
   consumer" approach to synchronizing threads.  (Whichever thread issues   
   the new io request is the producer, and the main thread that queues up   
   the asynchronous io requests is the consumer.  The producer signals a   
   condition variable to let the consumer know that there is something to   
   "consume.")   
      
   > The second option would be easier to implement and also would result   
   > in less latency for each set of IO requests as waking up a blocked   
   > thread is faster than creating a new one. Are there downsides to   
   > keeping an active thread alive in the blocked state?   
      
   Essentially no downside.  (If you know that the blocked thread is   
   never to be used again, you might as well let it exit to free up the   
   modest resources used by a sleeping thread.)   
      
   > Is it really wasteful of resources?   
      
   No.  Threads are supposed to be reasonably light weight.  Only if you   
   have a lot these blocked threads would it be an issue.  If the only   
   thread we're talking about is your single main thread, it's not a   
   problem.   
      
   As Andy mentioned, the blocked thread uses some memory, but, for a   
   single thread, the amount is modest.   
      
   > Is it possible that on some implementations this would result in   
   > wasteful busy waiting by the other thread?   
      
   Well, anything is possible, but it would be a very poor implementation   
   that implemented condition variables in such a way.  A main point of   
   condition variables (and other synchronization objects such as   
   mutexes) is to let blocked threads sleep without wasteful busy   
   waiting.   
      
   (My experience is the same as Andy's -- I've never come across an   
   implementation where the blocked threads spin, consuming cpu.)   
      
   > Thank you for your help!   
      
   Good luck.   
      
      
   K. Frank   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)