Re: Threads: incompatibilities between C and C++?
Rani Sharoni wrote:
On May 14, 10:14 pm, Pete Becker <p...@versatilecoding.com> wrote:
The difference in the signatures of the called functions comes
about because thrd_create takes a function pointer of type
int(*)(void*); in C++, the std::thread constructor takes an
arbitrary callable type and an appropriate argument list.
This isn't properly called "an incompatibility", however. The
underlying design models are quite different.
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>(f)), DECAY_COPY (std::forward<Args>(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.
Can you explain a bit more what exactly is the origin of the
performance penalty? You write that the caller has to wait for the new
thread to copy something - but I can not see why that is the case. As
is stated in the quote from the C++ standard above, the copies are
made in the calling thread.
Or is your point that copies are made at all?
[...]
Example for why the wait is needed:
struct A {};
void func(A&) {}
I believe this is not a valid signature for a thread routine:
DECAY_COPY returns an rvalue, which does not bind to A&. A quick test
with GCC 4.7.0 seems to agree, with A& a compile error is reported,
A&&, A const& and plain A all compile.
void f()
{
A a = {};
// copy of 'a' is done by the new thread
// hence f() has to wait to keep the source alive
std::thread(func, a);
}
As written above, I do not see any requirement that the *new* thread
makes any copy. A test with GCC 4.7.0 also shows that all copies are
made in the calling thread.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]