Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #839

Re: std::thread - abstraction penalty

Followups directed to: comp.programming.threads

Show key headers only | View raw

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.

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

std::thread - abstraction penalty Rani Sharoni <ranisharoni75@gmail.com> - 2012-03-11 14:13 -0700
  Re: std::thread - abstraction penalty Joshua Maurice <joshuamaurice@gmail.com> - 2012-03-12 15:27 -0700
    Re: std::thread - abstraction penalty Rani Sharoni <ranisharoni75@gmail.com> - 2012-03-13 01:43 -0700
      Re: std::thread - abstraction penalty Joshua Maurice <joshuamaurice@gmail.com> - 2012-03-13 15:07 -0700
  Re: std::thread - abstraction penalty Ulrich Eckhardt <doomster@knuut.de> - 2012-03-13 09:53 +0100
    Re: std::thread - abstraction penalty Rani Sharoni <ranisharoni75@gmail.com> - 2012-03-13 07:27 -0700

csiph-web