What's the connection between objects and threads?

J

James Kanze

You should know it,

Since I'm one of the experts in the French national body, yes.
I'm very much aware about what is going into the standard.
since you were trolling in the other discussion
thread in "Threading in new C++ standard" too,

The only troll in that thread was you. You refuse to read and
understand the published documentation, and you've obviously no
real experience with large working multithreaded applications,
but you continue with argumentive posts questionning the
competence of the real experts.
that threads are not
going to be included at the language level in C++0x. You were
corrected there by people taking part in C++0x standardisation.

And that is simply a lie.
Threading will be included at the library level only. Check
out the C+ +0x document proposal and report here if you can
find in it any language elements for defining any computation
process at the language level.

Threading is handled in �1.9 of the latest draft (amongst other
places). This was pointed out to you in the other thread as
well, but you refuse to read anything which doesn't conform to
your prejudices.
No, that does not, especially since threads will not appear at
the language level in C++0x. Even if computational processes
were included at the language level, it does not necessarily
mean that computational processes and objects must be related
and I have pointed that out earlier in this discussion!
(Please read the posts, do not just troll into them.)

The only thing you've done to date is make a lot of vacuous
claims, unsupported by any real facts. The experts in the
matter don't share your prejudices. Nor do those of us actually
involved in writing working applications.
 
I

Ian Collins

Chris said:
Also, 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.

I was saving that one for the next round!
 
S

Szabolcs Ferenczi

The pseudo-code I post over on 'comp.programming.threads' is all about the
__experimental__ synchronization algorihtms that I am brainstorming. We have
been over this before Szabolcs. If I come up with an idea, I try to make
sure to post it on c.p.t. If there is a typo in the pseudo-code, I promptly
document them and show the corrections. Anyway...


Unfortunately, wrt this thread, your so-called help is only going to lead
the OP down the wrong path. You don't seem to get it. AFAICT, the OP wanted
to create a thread base class for users to derive from. Something like:
____________________________________________________________________
class thread_base {
  pthread_t m_tid;
  virtual void on_entry() = 0;

  thread_base() {
  }

  virtual ~thread_base() throw() = 0;

};

thread_base::~thread_base() throw() {}
____________________________________________________________________

The OP cannot start the thread from the constructor of the base class! This
is what I was referring to. When threads are involved there is a major
race-condition because the thread can be started and call the on_entry pure
virtual function which results in UB. Also, even in the absence of threads
there still can be a problem. Here is a VERY simple example:
____________________________________________________________________
#include <cstdio>
#include <cstdlib>

static void call_abstract_virtual_indirect(class base*);

class base {
  friend void call_abstract_virtual_indirect(class base*);
  virtual void on_action() = 0;

public:
  base() {
    call_abstract_virtual_indirect(this);
  }

  virtual ~base() throw() = 0;

};

base::~base() throw() {}

void call_abstract_virtual_indirect(base* _this) {
  _this->on_action();

}

class derived : public base {
  int const m_ctor;

public:
  derived() : m_ctor(123456789) {

  }

private:
  void on_action() {
    std::printf("(%p)::derived::eek:n_action()\n", (void*)this);
    if (m_ctor != 123456789) {
      std::printf("(%p)::derived::eek:n_action() - NOT CONSTRUCTED!\n",
(void*)this);
      std::getchar();
      std::abort();
    }
  }

};

int main() {
  {
    derived d;
  }

/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
  std::puts("\n\n____________________________________________\n\
Press <ENTER> to exit...");
  std::getchar();
  return 0;

}

____________________________________________________________________

The above demonstrates ...

Well, the above demonstrates that a hacker can misuse any formal
system.

Kurt Goedel can be very pleased now up there since slaves are working
for him down here.

Congratulations!

Best Regards,
Szabolcs
 
S

Szabolcs Ferenczi

Well there isn't a reference, because it isn't defined.

If you cannot give any reference what are you referring to then? What
is the specified scenario? Reference please to the specified scenario.
You are talking about something that is not defined?
 The C++
standard makes no mention of threads

That is what I have started my contribution with to this discussion
thread.
"C++ does not have the notion of the process or the thread of
computation at the language level."
http://groups.google.com/group/comp.lang.c++/msg/6413d1c864883be3
Good morning. At least you woke up now.
and POSIX for one does not define
the which thread is running after pthread_create.  Either the parent,
the child or both may be running after the thread is created.

Who argues with you in that? You should not make any assumption about
the relative speed of the threads of computation.
I'm not, an object is not complete until its constructor returns.

Reference please. Where is it defined in the C++ standard? A
constructor is just a method that is called automatically. It is your
responsibility to fully initialise the state space you are using and
you can do that in the constructor. Once you are done with it, it is
complete. So simple is it.

Again you are invited to give a reference to prove your claim. Until
you cannot prove any reference, you are mistaken.
Provided the virtual function is defined in the class or a base class.

Where else? Are you trying to argue with the standard now? I have
quoted from the standard.
Say the constructor uses one or more RAII style objects to manage
resources, even though the thread creation is the last visible call in
the constructor, the managed objects still have to be destroyed.

Yes, so arrange it that your managed objects should be destroyed. Once
you introduce some hack, you have to do that properly. You must
arrange that your managed objects be destroyed properly.
 Say
one of these operations fails and throws an exception which isn't
handled in the constructor.

Well, you must handle it in the constructor. If you do not handle it
in the constructor, it is your fault. Simple, isn't it?
 The constructor will then throw an
exception and the object's members will be cleaned up and the object
will not have been constructed.  But the thread will still be running...

If you build your code like that, yes, you are in trouble.

However, with the same effort one can program it properly as well. For
instance, you can try try. Define your RAII hack in a try block, catch
and handle exceptions and when everything is finished properly, you
can launch the thread safely. Otherwise you must cach and handle the
exception. Can't you do that? What is your problem?

So, where are the incomplete objects after all?

Earlier you said: "All I claim is that launching a thread in a
constructor invokes undefined behaviour. Nothing more, nothing less."
http://groups.google.com/group/comp.lang.c++/msg/856389deef6a40c0

Please prove that claim of yours. Nothing more, nothing less. Where is
the undefined behaviour?

Best Regards,
Szabolcs
 
S

Szabolcs Ferenczi

Since I'm one of the experts in the French national body, yes.
I'm very much aware about what is going into the standard.

Very well. That explains a lot about the French contribution. You like
to talk big, don't you.
And that is simply a lie.

Is it?

Why do not you just calm down? Are you so notorious.

How about this:

<quote>
23. Pete Becker View profile More options Apr 20, 7:04 pm
There was never a proposal for introducing the
threading API at the language level, however; that just seems
contrary to the basic principles of C++, and in practice, is
very limiting and adds nothing.

There actually was a proposal for threading at the language level:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1875.html.
....
</quote>
http://groups.google.com/group/comp.lang.c++/msg/1ea5fdf80fd7f461

Q.E.D.

Best Regards,
Szabolcs
 
S

Szabolcs Ferenczi

And the implementations I use are completely thread safe, not
just to a certain extent.

After all your talking big, I doubt it, but if you wrapped the STL up,
maybe. But I am not sure about you.

Can you show me how do you solve with plain STL container that two
consumer process are awaiting elements?

No, you can't, until you wrap the STL and make the wrapped container
thread safe.

Best Regards,
Szabolcs
 
S

Szabolcs Ferenczi

Where does the current C++ standard say that the STL is "thread-safe to a
certain extent"???

For instance here:
"The SGI implementation of STL is thread-safe only in the sense that
simultaneous accesses to distinct containers are safe, and
simultaneous read accesses to to shared containers are safe. If
multiple threads access a single container, and at least one thread
may potentially write, then the user is responsible for ensuring
mutual exclusion between the threads during the container accesses. "

http://www.sgi.com/tech/stl/thread_safety.html

Best Regards,
Szabolcs
 
S

Szabolcs Ferenczi

Yes. Copying a process with fork() is very fast. You don't get much of a
performance boost from using threads.

Did you ever hear about heavy weight and light weight processes? I am
just curious.

Best Regards,
Szabolcs
 
G

gpderetta

And that is simply a lie.

Is it?
[...]

How about this:

<quote>
23.  Pete Becker    View profile   More options Apr 20, 7:04 pm
There was never a proposal for introducing the
threading API at the language level, however; that just seems
contrary to the basic principles of C++, and in practice, is
very limiting and adds nothing.

There actually was a proposal for threading at the language level:http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1875.html.
...
</quote>http://groups.google.com/group/comp.lang.c++/msg/1ea5fdf80fd7f461

Q.E.D.

Nope:

"threading API at the language level" != "threading at the language
level"

C++ will have threading at the language level, but you will not be
able to
access the threading primitives via keywords; instead, you will have
to access
them through standard library based wrappers. Of course an
implementer,
as a conforming extension, is free to expose the underlying
implementation primitives,
if there are any.
 
G

gpderetta

Did you ever hear about heavy weight and light weight processes? I am
just curious.

On modern unices, there isn't much of a difference between a process
and a thread,
except that processes do not share the address space (and other minor
differences).
Unsharing is done with copy on write, so as long as the child process
do not touch
parent data, forking is very, very, fast.

Context switching a process instead of a thread requires, on modern
architectures,
invalidating the TLB (but there are ways around that), which is
moderately expensive,
but not excessively so (with a big enough timeslice, you won't notice
the difference).

HTH,
 
G

gpderetta

For instance here:
"The SGI implementation of STL is thread-safe only in the sense that
simultaneous accesses to distinct containers are safe, and
simultaneous read accesses to to shared containers are safe. If
multiple threads access a single container, and at least one thread
may potentially write, then the user is responsible for ensuring
mutual exclusion between the threads during the container accesses. "

http://www.sgi.com/tech/stl/thread_safety.html

Yes, in that sense is thread safe.

In fact, short of having transactional memory (which allows arbitrary
composition of atomic operations) it is, arguably, the only useful
sense.

Unfortunately (efficient) transactional memory is mostly an academic
topic.

BTW, IIRC the incoming C++ standard will guarantee the same thread
safety
stated in the SGI document (which is, of course, not the standard).
 
G

gpderetta

Please explain it to the forum fighters.

No need. They all, especially James Kanze, know very well.

That's way they say that it is completely thread safe: as long
as you follow some simple rules, most standard library
implementations work perfectly well in threaded programs.
 
G

gpderetta

Are you suggesting that he intentionally makes fool of himself?http://groups.google.com/group/comp.lang.c++/msg/bf81088bfec40dab

Please, let's grow up. I do not see how James makes fool of himself.
Quite the contrary in fact.
Or do you rather think that he just gets excited whenever he sees any
statement from me and he starts contradicting anything just blindly?
Is it a conditioned reflex by him then?

No, it is just that this is a very high volume C++ newsgroup, and
any incorrect statement which goes uncorrected might confuse
newbies (or even experts which are not familiar with some niche
details).

Let's continue this discussion just on a technical level.
 
R

Rolf Magnus

darren said:
I was reading this tutorial, and a table in the document describes a
process as being about 50x more expensive than a thread. Maybe I'm
interpreting the table wrong.

I tried the test programs from that table on my system, and the factor there
was around 7. Anyway, such a comparison doesn't say much, since a
real-world program does some actual work and not just spawn off
processes/threads. And then, it only matters how much time the spawning
costs compared to the time for the actual work.
 
J

James Kanze

After all your talking big, I doubt it, but if you wrapped the STL up,
maybe. But I am not sure about you.

I haven't wrapped anything. And judging from your previous
postings, I doubt you know what thread safety means, so I'm not
sure what your doubting means.
Can you show me how do you solve with plain STL container that
two consumer process are awaiting elements?

Can you ask a question that makes sense. STL containers are
data containers, they aren't thread synchronization elements.
No, you can't, until you wrap the STL and make the wrapped
container thread safe.

As I said, it's obvious that you don't know what "thread safe"
means.
 
J

James Kanze

For instance here:
"The SGI implementation of STL is thread-safe only in the sense that
simultaneous accesses to distinct containers are safe, and
simultaneous read accesses to to shared containers are safe. If
multiple threads access a single container, and at least one thread
may potentially write, then the user is responsible for ensuring
mutual exclusion between the threads during the container accesses. "

As others will no doubt point out, that document isn't the
standard, and only applies to a specific implementation. Other
than that, can you give some other definition of "thread safe"
which would be applicable to the standard containers. That is
not "thread-safe to a certain extent", that is "thread-safe",
pure and simple.
 
J

James Kanze

On May 19, 7:10 pm, Szabolcs Ferenczi <[email protected]>
wrote:

[...]
Yes, in that sense is thread safe.
In fact, short of having transactional memory (which allows
arbitrary composition of atomic operations) it is, arguably,
the only useful sense.

I'm not too sure what you mean by transactional memory. In
general, however, containers that's the only useful sense of
thread safety for containers which "leak" references to internal
objects.

More importantly: the implementor here has *documented* the
contract which the implemention provides. And *that* is the key
meaning behind thread safety. Thread safety is first and
foremost a question of documentation.
Unfortunately (efficient) transactional memory is mostly an
academic topic.

Aha. That's why I'm not too familiar with it.
BTW, IIRC the incoming C++ standard will guarantee the same
thread safety stated in the SGI document (which is, of course,
not the standard).

That's the basic intention. I believe that there are a few
small open issues, but the basic philosophy is the same as that
in the SGI implementation.
 
J

James Kanze

Are you suggesting that he intentionally makes fool of
himself?http://groups.google.com/group/comp.lang.c++/msg/bf81088bfec40dab

Do you understand English? The SGI statement says exactly what
I said, that the implementation is thread safe. (At least two
of the implementations I use are derived almost directly from
the SGI implementation.)

The problem I see here is that you don't know what thread-safe
means.
Or do you rather think that he just gets excited whenever he
sees any statement from me and he starts contradicting
anything just blindly? Is it a conditioned reflex by him
then?

It's a more or less conditioned reflex on my part to correct
errors which people post, so that beginners don't get mislead.
The fact that you tend to post mostly errors does lead to my
correcting your postings more than those of other people.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top