b300ef08   
   From: ulrich.eckhardt@dominolaser.com   
      
   Am 15.05.2012 19:20, schrieb Rani Sharoni:   
   > I also noticed a potential abstraction penalty associated with   
   > std::thread. Per the C++ standard 30.3.1.2/4 (thread   
   > construction): The *new thread of execution executes* INVOKE(DECAY_-   
   > COPY( std::forward(f)), DECAY_COPY (std::forward(args))...)   
   > with the calls to DECAY_COPY being evaluated in the constructing   
   > thread.   
   >   
   > This means that in general the caller thread has to wait for the new   
   > thread copying - serialization penalty that doesn't exist for the raw   
   > C interface. I guess that the requirement (feature) is meant to allow   
   > TLS sensitive copying or some sort of transfer-of-ownership though I   
   > can't think about any realistic use case relaying on such feature.   
      
   I don't see any use related to tread-local storage, but transfer of   
   ownership seems like a reasonable goal to me. Think of a job queue and a   
   thread pool. The managing thread pops a job off the queue and passes it   
   to a worker thread. If the thread pool is empty, i.e. no worker thread   
   available, you don't want the job object to be discarded.   
      
   > I already noticed that the VC implementation is taking the penalty for   
   > every call including when passing raw-pointers or lambda.   
   > Thread pools with similar interface might have the same problem (which   
   > is more severe for pools).   
      
   For the thread pool, I'd say it's less severe, assuming you already have   
   a few threads running. The reason is that the startup time for the new   
   thread is avoided, you only need to notify a waiting thread that there   
   is a function for it to run.   
      
   That said, I agree that this is far from optimal for performance and I   
   also wonder if this is a mere oversight or if there is a good   
   explanation. Maybe that explanation is simply that if you really care   
   for startup latency, you should start your thread before you really need   
   it, i.e. take the thread-pool approach above. OTOH if you need complete   
   startup feedback including for initialisations that are done by the   
   started thread and which might fail, you can't live without this.   
      
   Uli   
      
      
   --   
         [ 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)