Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!not-for-mail From: Ulrich Eckhardt Newsgroups: comp.programming.threads Subject: Re: std::thread - abstraction penalty Followup-To: comp.programming.threads Date: Tue, 13 Mar 2012 09:53:01 +0100 Lines: 47 Message-ID: <9s8g7fF18hU1@mid.uni-berlin.de> References: <6cd50e44-6888-4f0a-94fa-a736b0d877da@k24g2000yqe.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de Zwb26LWvTolDhPxjmRDr+Q7Nf0NBC6zzD1Z/gLQy6UYfVCNAw= User-Agent: KNode/4.4.11 Xref: csiph.com comp.programming.threads:839 Rani Sharoni wrote: > I recently encountered std::thread implementation in which the caller > thread waits for target threads to start and evaluate arguments before > continuing. This seems to create a sub-optimal serialization due to > potential use cases that might rarely be used (e.g. TLS sensitive > copying and custom transfer of ownership). I beg to differ here: Transferring ownership is not uncommon. Actually, I find it very common that a thread operates on some context object and that it either exclusively owns that object or shares ownership. The shared ownership case (shared_ptr) is easily solved, because you just copy the smart pointer object, the caller can't tell the difference anyway. However, in order to get the exclusive ownership case right, you pass an auto_ptr [1] to the function starting the thread. If this function fails to start the thread you should retain ownership of the resource [2], so it can't blindly copy the smart pointer. Instead, it must provide the smart pointer as a reference to the thread startup function, but then it has to wait until that function has "picked up" the resource from that reference. One thing that contradicts this theory is the fact that the "DECAY-COPY" operations are running in the constructing thread and I would expect these to already transfer ownership. But maybe I'm reading something into those statements that isn't there, I don't have the full text at hand. Note that I'm only guessing the rationale for this requirement, which indeed penalizes the startup latency. In most cases, the C++ Committee is not blind though and also concerned with speed, so I wouldn't rule out ways to get around this. One thing I would look at are thread pools, I know that at least Boost.Thread has an according class. Greetings! Uli [1] I'm aware of unique_ptr and that auto_ptr is deprecated, but I'm not 100% sure about its capabilities and behaviour. It is also intended for exclusive resource ownership though, so I guess it will be comparable. [2] You could argue differently, i.e. that once you try to start the thread you yield any claims to the resource. I guess this option was rejected, because it might do surprising things in the rare case that thread startup fails, which would then probably catch people unaware.