Mutex/Lock

[Szabolcs Ferenczi]

For the last time: you can only call virtual methods overridden in the
class being constructed or it bases (12.7.3).

Well done. Respect this rule and do not talk about a misbelief of
incomplete or not fully constructed object.

Best Regards,
Szabolcs

 

[peter koch]

[...]
All you said was that
starting threads in ctors is no big deal if you know what your doing.

Correct. And I still hold that claim. Your friend and you were trying
to contradict that but you failed.

Well,
the OP was on the verge of making a mistake, and I felt the need to put up a
big warning sign. So be it.

You have given a false warning. That is it.

No. That warning was not false. Dealing with threads is not
straightforward, and you have to be at least a little bit careful.

That is a basic misunderstanding on your side. There is no language
rule that would support your claim. In fact, the language rule states
that:

"Member functions, including virtual functions (10.3), can be called
during construction or destruction"

This is true, of course. But you have to be careful: when calling a
virtual function you call the function of the currently creating type,
not the final virtual function. So you can't get your thread to work
on the data of the resulting function.

There is no concept of not `fully constructed object' with respect to
calling its own methods. It is allowed to call any method during
construction. On the other hand, the object must be fully constructed
if you are trying to use it from its external environment. This is
what you wrongfully interpret in this case.

It is an error according to some C++ hackers only. It is not an error
according to any language rule.

Lots of stuff is not an error according to language-rules. Still,
theres a lot of rules outside of the pure language that you better
follow that you should follow unless you really know what you are
doing (and in that case, you probably won't violate them because you
know a better way of getting things done).

Agreed. So you nicely contradict yourself since you start the thread
in the constructor of the proxy and according to your own reasoning
the object is `not fully constructed' yet. Formally speaking. Or do
you think that in this case you know what you are doing and you can
fake your own principle?

In that case, the object the thread works on will be fully
constructed, so theres not a problem here (I do not know the code of

Do you mean that there are some C++ hackers who are educated enough so
that they are aware of the concept of active objects?

There is a unpleasant condescending tone of most of your posts here.
Better get rid of that tone, especially considering the lack of
contribution you have provided so far.

/Peter

 

[Szabolcs Ferenczi]

[...]
All you said was that
starting threads in ctors is no big deal if you know what your doing.

Correct. And I still hold that claim. Your friend and you were trying
to contradict that but you failed.

You have given a false warning. That is it.

No. That warning was not false.

If that was not false, you are invited to prove the claim.

Dealing with threads is not
straightforward, and you have to be at least a little bit careful.

Yes, that is why you should get rid of the low level stuff you are
fully supporting in the other discussion threads about threading in C+
+0x just because you are not educated enough in concurrent
programming.

[...]

"Member functions, including virtual functions (10.3), can be called
during construction or destruction"

This is true, of course. But you have to be careful: when calling a
virtual function you call the function of the currently creating type,
not the final virtual function. So you can't get your thread to work
on the data of the resulting function.

I was talking about disciplined usage all along. Your hacker friends
came with absurd constructions so you are really warning them.

[...]
Lots of stuff is not an error according to language-rules. Still,
theres a lot of rules outside of the pure language that you better
follow that you should follow unless you really know what you are
doing (and in that case, you probably won't violate them because you
know a better way of getting things done).

So I really know what I am doing and I can reason about it as well. On
the other hand you and your mates here cannot prove that claim about
incomplete object or not fully constructed object thing. So what are
you talking about?

In that case, the object the thread works on will be fully
constructed, so theres not a problem here (I do not know the code of
active<T>, but I presume this is the case.

You do not really follow the discussion, do you? The pointer has been
given a couple of posts before:
http://groups.google.com/group/comp.lang.c++/msg/20c14991f9e88482

This certainly is the case
in my thread templateclass).

So you contradict yourself too if you object me since you just claimed
you do what you are just opposing.

Let me ignore your personal stuff at the end of your mail. Please try
to be professional.

Best Regards,
Szabolcs

 

[Chris Forone]

[ ... ]

If the threading is implemented as a base class with an abstract
virtual function representing the threads "entry" point, then you simply
cannot create the thread in the constructor. The thread might start
running
and call the virtual function before the derived object has even had a
chance to run its ctor; OOPS!

You can _create_ the thread, but you must ensure against it _running_
until the ctor has finished executing.

AFAICT, this will won't work as far as the threading base-class ctor is
concerned. You would need to create suspended and only resume it when
all of the derived class are fully constructed. This is where the little
`active<T>' helper can be of service. Just create an object which has
`T::start()/join()' member functions, and create said object with
`active<T>' and your done.

http://groups.google.com/group/comp.lang.c++/msg/20c14991f9e88482
______________________________________________
class object {
[...];
public:
void start() { [...]; }
void join() { [...]; }
};

int main() {
{
active<object> my_object;
}
return 0;
}

______________________________________________


Simple.

I can't say with certainty that
all environments support creating threads in a suspended state, but some
(e.g. Win32) certainly do.

Indeed.

Why not locking the ctor?

best regards, chris

 

[Ian Collins]

Let me ignore your personal stuff at the end of your mail. Please try
to be professional.

Pot, kettle.

 

[Ian Collins]

Why not locking the ctor?

Do you mean hold the thread on a lock? If so, yo then have to add a
method to unlock, which defeats the imagined advantage of starting a
thread from a constructor.

 

[James Kanze]

[...]
All you said was that starting threads in ctors is no big
deal if you know what your doing.

Correct. And I still hold that claim. Your friend and you were
trying to contradict that but you failed.

The only one who's failed anything here is you. I'd suggest
that you finish high school before trying to teach professionals
things you apparently know nothing about.

You have given a false warning. That is it.

No. He gave an important warning. The fact that you don't
understand it just proves your lack of experience.

 

[peter koch]

On 2 Jun., 20:27, Szabolcs Ferenczi <[email protected]>
wrote:

[...]
All you said was that
starting threads in ctors is no big deal if you know what your doing..
Correct. And I still hold that claim. Your friend and you were trying
to contradict that but you failed.
Well,
the OP was on the verge of making a mistake, and I felt the need to put up a
big warning sign. So be it.
You have given a false warning. That is it.

No. That warning was not false.

If that was not false, you are invited to prove the claim.

It is easy to point to the numerous classes created by inexperienced
people where the code turns up to not work correctly, and that is all
it takes to give a warning. This is what a warning is all about: there
is nothing in the statement that tells that correctly working code is
impossible to get to work correctly, and in particular no claim that
such code can't be created.

Yes, that is why you should get rid of the low level stuff you are
fully supporting in the other discussion threads about threading in C+
+0x just because you are not educated enough in concurrent
programming.

What low-level code did I support? I do not remember having argued
about using low-level constructs. On the contrary, I have always
supporting using high-level constructs.

[...]

"Member functions, including virtual functions (10.3), can be called
during construction or destruction"

This is true, of course. But you have to be careful: when calling a
virtual function you call the function of the currently creating type,
not the final virtual function. So you can't get your thread to work
on the data of the resulting function.

I was talking about disciplined usage all along. Your hacker friends
came with absurd constructions so you are really warning them.

[...]
Lots of stuff is not an error according to language-rules. Still,
theres a lot of rules outside of the pure language that you better
follow that you should follow unless you really know what you are
doing (and in that case, you probably won't violate them because you
know a better way of getting things done).

So I really know what I am doing and I can reason about it as well. On
the other hand you and your mates here cannot prove that claim about
incomplete object or not fully constructed object thing. So what are
you talking about?

In that case, the object the thread works on will be fully
constructed, so theres not a problem here (I do not know the code of
active<T>, but I presume this is the case.

You do not really follow the discussion, do you? The pointer has been
given a couple of posts before:http://groups.google.com/group/comp.lang.c++/msg/20c14991f9e88482

I haven't read all posts, but I do not see how Thomassons active-
template is relevant to these posts: again, I never did claim that
writing a thread-wrapper class is impossible - only that it is not
easy to get correct. Also, I don't believe that you can have a generic
template-class that will work without using template code, and this is
just one more reason to warn newbies against creating such a class.

So you contradict yourself too if you object me since you just claimed
you do what you are just opposing.

Again, I never did oppose that.

Let me ignore your personal stuff at the end of your mail. Please try
to be professional.

Even better: why don't you try to get professional - e.g. by providing
something useful to this group. Let me recommend that you post a class
that works correctly and provides the needed functionality. It should
be quite a simple job according to yourself.

/Peter

 

[Szabolcs Ferenczi]

On 2 Jun., 23:48, Szabolcs Ferenczi <[email protected]>
wrote:
[...]

Yes, that is why you should get rid of the low level stuff you are
fully supporting in the other discussion threads about threading in C+
+0x just because you are not educated enough in concurrent
programming.

What low-level code did I support? I do not remember having argued
about using low-level constructs. On the contrary, I have always
supporting using high-level constructs.

If you do not remember, I can fresh up your memory. Here you go:
http://groups.google.com/group/comp.lang.c++/msg/1f57c21f016ad3e2

I suggested including high level concurrency constructions in C++0x at
the language level and you were at least not supporting it in favour
of the low level library-based solution.

Q.E.D.

I hope I was of help.

Best Regards,
Szabolcs

 

[peter koch]

On 2 Jun., 23:48, Szabolcs Ferenczi <[email protected]>
wrote:
[...]

Dealing with threads is not
straightforward, and you have to be at least a little bit careful.
Yes, that is why you should get rid of the low level stuff you are
fully supporting in the other discussion threads about threading in C+
+0x just because you are not educated enough in concurrent
programming.

What low-level code did I support? I do not remember having argued
about using low-level constructs. On the contrary, I have always
supporting using high-level constructs.

If you do not remember, I can fresh up your memory. Here you go:http://groups.google.com/group/comp.lang.c++/msg/1f57c21f016ad3e2

That post refers to your ignorance of the need to have a memory-model
that specifies behaviour in a multithreaded program.

I suggested including high level concurrency constructions in C++0x at
the language level and you were at least not supporting it in favour
of the low level library-based solution.

My conclusion: you are a fool!

/Peter

 

[Szabolcs Ferenczi]

On 2 Jun., 23:48, Szabolcs Ferenczi <[email protected]>
wrote:
[...]
Dealing with threads is not
straightforward, and you have to be at least a little bit careful.
Yes, that is why you should get rid of the low level stuff you are
fully supporting in the other discussion threads about threading in C+
+0x just because you are not educated enough in concurrent
programming.
What low-level code did I support? I do not remember having argued
about using low-level constructs. On the contrary, I have always
supporting using high-level constructs.

If you do not remember, I can fresh up your memory. Here you go:http://groups.google.com/group/comp.lang.c++/msg/1f57c21f016ad3e2

That post refers to your ignorance of the need to have a memory-model
that specifies behaviour in a multithreaded program.

Well, you do not need any low level so-called memory model if you have
concurrency constructs at the language level. You only `need'
something like the very low level memory model if you do not have high
level programming tools available at the language level but you work
with low level library elements. This is the answer to your question
`What low-level code did I support?' You support the low level memory
model instead of the high level concurrency language tools. Q.E.D.

At the same time you nicely unveil the truth behind this: `On the
contrary, I have always supporting using high-level constructs.' In
fact, you did not.

Let me ignore your unprofessional and nasty insult at the end of your
post. Please refrain from personal insults and try to be professional.
Thanks.

Best Regards,
Szabolcs

 

[Jerry Coffin]

[ ... ]

AFAICT, this will won't work as far as the threading base-class ctor is
concerned.

Presumably, that was intended to say "still won't work"...

You would need to create suspended and only resume it when all of
the derived class are fully constructed.

That much is correct -- but that doesn't mean it won't work, only that
you have to wait for all the ctors to finish before allowing the thread
to execute.

I certainly wouldn't argue that this is necessarily the best design, but
it certainly IS possible, at least on systems that allow you to create a
thread in a suspended state.