Re: Threads: incompatibilities between C and C++?
On May 21, 4:22 pm, Volker Lukas <vlu...@gmx.de> wrote:
Rani Sharoni wrote:
One might argue to additional copying is allowed but then why
mandating the copying in the new thread?
Again, I only see a requirement that the calling thread makes a copy
of the function object and the arguments: "[...] with the calls to
DECAY_COPY being evaluated in the constructing thread." .
Question: How do you interpret "constructing thread"? Does this mean
to you the the new thread of execution, that which was just started,
or does it mean to you the old thread, that which constructed the
std::thread object?
To me, it means the latter.
Ok. I think that you read this text better than me.
I looked at the boost::thread doc and it explicitly says the same.
The implementations you mentioned conforms without the wait penalty.
30.3.1.2/5 might add a bit more to my confusion:
"Synchronization: The completion of the invocation of the constructor
synchronizes with the beginning of the invocation of the copy of f."
I'm not sure about the meaning of this paragraph and why it's actually
required.
I guess that the intention is that the caller waits to report for
potential failures in the new thread before the invocation of 'f'.
The text might be confusing though but the second implementation you
mentioned seem to have related bug (see below).
BTW - can you debug into the GCC implementation to see if it
waits? VC for sure does.
I can not see anything which I would call "waiting", i.e. I do not
see any waiting on condition variables, mutexes, semaphores etc...
This is how std::thread is implemented for GCC:
http://gcc.gnu.org/viewcvs/trunk/libstdc++-v3/include/std/thread?revision=184997&view=markup
Thanks for checking this. I also looked at libc++ code you mentioned
and no wait in sight there:
thread(_Callable&& __f, _Args&&... __args)
{
_M_start_thread(_M_make_routine(std::__bind_simple(
std::forward<_Callable>(__f),
std::forward<_Args>(__args)...)));
}
I see an extra allocation for the args holder type (via shared_ptr)
but this is probably negligible compared with the thread creation
(native C interface doesn't require such).
For this program,
I get this output (GCC 4.7.0 + supplied library implementation):
main, thread id = 139890527434560
A(A const&, thread id = 139890527434560
A(A&&, thread id = 139890527434560
f, thread id = 139890510874368
So any copies of the function object and its argument are made in
the old thread. This is in line with my reading of the C++ standard
(N3376 draft).
Thanks. definite proof that copying is done by the caller thread.
There is also an alternate implementation of std::thread, as part of
the LLVM project:
http://llvm.org/svn/llvm-project/libcxx/trunk/include/thread
That implementation also makes the copies in the calling thread,
like with GCC.
Indeed:
thread::thread(_Fp&& __f, _Args&&... __args)
{
typedef tuple<typename decay<_Fp>::type, typename
decay<_Args>::type...> _Gp;
_VSTD::unique_ptr<_Gp> __p(new
_Gp(__decay_copy(_VSTD::forward<_Fp>(__f)),
__decay_copy(_VSTD::forward<_Args>(__args))...));
int __ec = pthread_create(&__t_, 0, &__thread_proxy<_Gp>,
__p.get());
But there seem to be a bug in the underlying callback:
__thread_proxy(void* __vp)
{
// throwing new will terminate
__thread_local_data().reset(new __thread_struct);
std::unique_ptr<_Fp> __p(static_cast<_Fp*>(__vp));
typedef typename __make_tuple_indices<tuple_size<_Fp>::value,
1>::type _Index;
__threaad_execute(*__p, _Index());
In this case the implementation should propagate the exception to the
caller thread that has to wait.
Better to simply pre-allocate this __thread_struct in the caller
thread.
Thanks,
Rani
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]