Hi
I have to write a multi-threaded program. I decided to take an OO
approach to it. I had the idea to wrap up all of the thread functions
in a mix-in class called Threadable. Then when an object should run
in its own thread, it should implement this mix-in class. Does this
sound like plausible design decision?
I'm surprised that C++ doesn't have such functionality, say in its
STL. This absence of a thread/object relationship in C++ leads me to
believe that my idea isn't a very good one.
I would appreciate your insights. thanks
Jun 27 '08
167  8112 
Rolf Magnus wrote:
ManicQin wrote:
>2) Darren is supposed to submit his project to his prof\tester
usually spliting your projects (IMHO) to sub processes gives it a...
(maybe unjustified) scent of a bad design... Most of my professors
were fixed on the notion that an application is one process. (I think that
spliting your process to subs is a concept that is more acknowledged in
linux \unix platforms then windows.
Not sure what you mean by "splitting your process to subs". Unix
traditionally does many of the things it wants to do parallel with separate
processes. Threads aren't used very often.
He used the term "sub processes" earlier in that paragraph.
Well that (Threads aren't used very often) was the case long ago, but
most things in Unix land (including the kernel) make heavy use of threads.
Since process creation is much more expensive under Windows, similar
programs need to use threads for performance reasons.
>AFAIK it's partially due to the reason that in linux you only
load your code once for all the instances of the application... or
something like
that... CMIIW!!!)
Yes. Copying a process with fork() is very fast. You don't get much of a
performance boost from using threads.
You do if you have lots or create/destroy them frequently. A thread has
a lot less baggage than a process (especially no Linux has a decent
thread model).
--
Ian Collins.
Yes. Copying a process with fork() is very fast. You don't get much of a
performance boost from using threads.
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. https://computing.llnl.gov/tutorials/pthreads/
In article <244547b2-0b90-45f1-a8f2-5ce84f7dd3e4
@k1g2000prb.googlegroups.com>, mi******@gmail.com says...
>
Yes. Copying a process with fork() is very fast. You don't get much of a
performance boost from using threads.
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.
https://computing.llnl.gov/tutorials/pthreads/
You seem to be interpreting the table correctly, but may not be
considering how that affects the server as a whole. The fact that one is
50x slower than the other doesn't mean that a server based on that model
would necessarily be 50x slower. Even though one's quite a bit faster
than the other, it creating new threads/processes should be a fairly
small percentage of overall time either way.
Of course, that depends heavily on the rest of the design. Quite a few
people try creating a new thread for every incoming connection. This
would almost certainly be disastrous if you created a new process for
every connection instead.
OTOH, if you create some sort of thread/process pool, then you only
incur that 50x overhead a few times while your server starts up. After
that, you might incur some overhead from inter- rather than intra-
process communication, but that's mostly a separate question.
--
Later,
Jerry.
The universe is a figment of its own imagination.
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:f9**********************************@2g2000hs n.googlegroups.com...
On May 18, 3:23 pm, James Kanze <james.ka...@gmail.comwrote:
Except that, as Chris has already pointed out, it results in a
race condition. It's a serious design error.
Well, he did not point out anything but claimed something. He has
postings that he used to correct the next hour or the next day.
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...
You better read carefully what I have written. I highlighted that one
needs discipline for it. It is hopless for you but at least you calm
down.
I hope I could help though.
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::on_action()\n", (void*)this);
if (m_ctor != 123456789) {
std::printf("(%p)::derived::on_action() - NOT CONSTRUCTED!\n",
(void*)this);
std::getchar();
std::abort();
}
}
};
int main() {
{
derived d;
}
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~*/
std::puts("\n\n___________________________________ _________\n\
Press <ENTERto exit...");
std::getchar();
return 0;
}
__________________________________________________ __________________
The above demonstrates one reason why its generally NOT a good idea to start
a thread in a constructor. Your failure to understand this is only going to
confuse the OP. Your advise is flawed in that respect. The problem produces
undefined-behavior. It can just seg-fault, or it might print "... NOT
CONSTRUCTED!", or whatever. Therefore, I guess the moral of the story is "Do
NOT call abstract virtual functions in constructors!"
:^o
"Ian Collins" <ia******@hotmail.comwrote in message
news:69**************@mid.individual.net...
Szabolcs Ferenczi wrote:
>On May 19, 1:25 am, Ian Collins <ian-n...@hotmail.comwrote:
>>You countered with "And the constructor does return. And the object is
fully constructed.". The new thread could run to completion before the
constructor returned,
It depends. If it is a disjoint thread (not likely), yes. And then
nothing wrong is with it. If the thread needs interaction and the
conditions are not met, the thread cannot run to completion before the
constructor returns, of course.
>>or the constructor could return before the thread
runs.
That is also possible. No problem with that.
>> Either is possible and neither is the specified scenario, because
there isn't one.
What do you mean by "neither is the specified scenario, because there
isn't one."? Reference?
Well there isn't a reference, because it isn't defined. The C++
standard makes no mention of threads 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.
>>Do you deny using an incomplete object doesn't invoke undefined
behaviour?
There is no incomplete object. You are mistaken in that.
I'm not, an object is not complete until its constructor returns.
>Let us take class A, you can use any method of class A in the
constructor of class A. (See "Member functions, including virtual
functions (10.3), can be called during construction or destruction")
Agreed?
Provided the virtual function is defined in the class or a base class.
>A thread started as the last step in the constuctor of class A can
equally well call any member of class A. Remember that by convention
(see discipline) members of class A are initialised already. If the
thead would access any object from classes other than A then obviously
those objects are constructed already otherwise the thread would not
have any reference to them.
So, where is your problem? Where are the incomplete objects?
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. Say
one of these operations fails and throws an exception which isn't
handled in the constructor. 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...
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. The thread might start running
and call the virtual function before the derived object has even had a
chance to run its ctor; OOPS! This is a major race-condition that Szabolcs
seems to think cannot ever happen. Perhaps I am misunderstanding him,
although, his arguments "seem" to suggest that he is not a C++ programmer...
;^/
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:53**********************************@a1g2000h sb.googlegroups.com...
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created and running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
:^/
Where does the current C++ standard say that the STL is "thread-safe to a
certain extent"???
[...]
On May 18, 10:41 pm, Ian Collins <ian-n...@hotmail.comwrote:
Szabolcs Ferenczi wrote:
On May 18, 3:23 pm, James Kanze <james.ka...@gmail.comwrote:
Except that, as Chris has already pointed out, it results in a
race condition. It's a serious design error.
Well, he did not point out anything but claimed something.
He has postings that he used to correct the next hour or the
next day.
You better read carefully what I have written. I highlighted
that one needs discipline for it.
Discipline or not, the practice is best avoided. Even if the
thread is started in the last (visible) instruction in a
constructor, the object is still not fully constructed until
the constructor returns.
Not to mention what happens if someone inherits from your class.
Starting the thread in a constructor is a well known
anti-pattern.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 19, 12:38 am, Gianni Mariani <gi4nos...@mariani.wswrote:
Ian Collins wrote:
...
You still have not addressed the fundamental issue of the
new thread using an object that has not been fully
constructed. Please provide example code that solves this
problem.
Almost all threaded code I have seen that works in a cross
platform is susceptible to the "problem" in a strict sense.
In practice, if the thread is "enabled" as the very last thing
in the most derived constructor, then there it is very
unlikely you're ever going to see a problem.
And how do you ensure that? About the only way I know is to use
a separate object for the actual thread behavior. This is what
Boost does. (Java uses a separate function to start the thread,
which also works well.)
I have yet to find an alternative that is acceptably straight
forward as this approach.
I'm not sure I understand you. Boost and Java use two radical
different models, yet both manage to avoid the problem.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 19, 12:58 am, Ian Collins <ian-n...@hotmail.comwrote:
Gianni Mariani wrote:
Ian Collins wrote:
....
You still have not addressed the fundamental issue of the
new thread using an object that has not been fully
constructed. Please provide example code that solves this
problem.
Almost all threaded code I have seen that works in a cross
platform is susceptible to the "problem" in a strict sense.
In practice, if the thread is "enabled" as the very last
thing in the most derived constructor, then there it is very
unlikely you're ever going to see a problem.
The problem is the thread class tends to be used as a base, so
this strict rule breaks down.
I have yet to find an alternative that is acceptably
straight forward as this approach.
I guess I was bitten by it too often in my formative years and
moved to the functor style now adopted by boost. Now I find
the boost style much more straight forward and less fragile.
The object used for the thread is always complete and in a
known state.
That is, IMHO, the cleanest solution. When it comes down to
it, the "object" you execute on isn't the thread; it's used by
the thread, so even from an OO point of view, it seems
preferable.
The alternative is to provide a separate function to start the
thread, as in Java. I personally don't see where this is a
problem either; it's just one additional function call after the
constructor. If the execution object has significant behavior,
it might even be preferable; it gives you a chance to intervene
after the constructor, but before the thread starts (e.g. to
register the object somewhere).
All in all, I don't really believe in the one size fits all
philosophy here, but if I had to stick to just one model, it
would be that of Boost, which executes a copy of the object you
pass it. It's a slight hassle in the case of joinable threads,
if you want to access the results in the thread object after the
join, but that's nothing that an extra layer of indirection
can't fix. (Back in the old days, it was widely believed that
there was no problem which couldn't be solved by an extra layer
of indirection:-).) (What bothers me most about the Boost model
is that if you miss catching an exception somewhere, you end up
with a detached thread, when what you wanted was to terminate
and join.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 19, 9:13 am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:53**********************************@a1g2000h sb.googlegroups.com...
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created and running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
:^/
Where does the current C++ standard say that the STL is
"thread-safe to a certain extent"???
And the implementations I use are completely thread safe, not
just to a certain extent. The document very clearly what is and
is not guaranteed (even if what they guarantee is somewhat
surprising in the case of g++, since it contradicts Posix).
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 18, 3:43 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 18, 3:27 pm, James Kanze <james.ka...@gmail.comwrote:
On 18 mai, 13:29, ManicQin <Manic...@gmail.comwrote:
On May 18, 12:43 pm, darren <minof...@gmail.comwrote:
[...]
Try to avoid using singletons (if you refer to the
singleton pattern). It is not a good idea even in
non-MT programs. You can always avoid using singletons
by disciplined programming. In this case you do not need
singleton either.
He is right
Bullshit. (If you read any of Szabolcs' postings, you'll
quickly realize that he's never actually written any real code.)
You don't want to abuse them, but there are special cases where
they are the appropriate solution. In the case of detached
threads, in fact, some form of singleton is almost necessary for
a clean shutdown.
Calm down, my friend, and do not write "Bullshit".
I call a spade a spade. If you don't post bullshit, I won't
respond with "bullshit".
If you do not know about something, do not attack it just
because of your ignorance.
Look who's talking.
The singleton pattern is discouraged even by its creator.
Given that the pattern has been around for years, I doubt that
we even know who its creator is. The fact remains that it is
the best known solution for a small number of particular cases.
Just because it can be (and frequently is) misused doesn't mean
it shouldn't be used where appropriate. (There is, in fact, no
other way to ensure clean shutdown if you're using detached
threads.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 18, 11:00 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 18, 9:59 pm, James Kanze <james.ka...@gmail.comwrote:
On 18 mai, 18:22, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 18, 3:56 pm, James Kanze <james.ka...@gmail.comwrote:
...
The next version of the standard will definitely support threads
at the language level; that much has been pretty well proven.
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.
... That
doesn't mean that objects and threads will necessarily be
related,
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
Chris Thomasson wrote:
>
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!
--
Ian Collins.
On May 19, 8:54*am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:f9**********************************@2g2000hs n.googlegroups.com...
On May 18, 3:23 pm, James Kanze <james.ka...@gmail.comwrote:
Except that, as Chris has already pointed out, it results in a
race condition. It's a serious design error.
Well, he did not point out anything but claimed something. He has
postings that he used to correct the next hour or the next day.
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...
You better read carefully what I have written. I highlighted that one
needs discipline for it. It is hopless for you but at least you calm
down.
I hope I could help though.
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::on_action()\n", (void*)this);
* * if (m_ctor != 123456789) {
* * * std::printf("(%p)::derived::on_action() - NOT CONSTRUCTED!\n",
(void*)this);
* * * std::getchar();
* * * std::abort();
* * }
* }
};
int main() {
* {
* * derived d;
* }
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~*/
* std::puts("\n\n___________________________________ _________\n\
Press <ENTERto 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
On May 19, 5:16*am, Ian Collins <ian-n...@hotmail.comwrote:
Szabolcs Ferenczi wrote:
On May 19, 1:25 am, Ian Collins <ian-n...@hotmail.comwrote:
You countered with "And the constructor does return. And the object is
fully constructed.". *The new thread could run to completion before the
constructor returned,
It depends. If it is a disjoint thread (not likely), yes. And then
nothing wrong is with it. If the thread needs interaction and the
conditions are not met, the thread cannot run to completion before the
constructor returns, of course.
or the constructor could return before the thread
runs.
That is also possible. No problem with that.
*Either is possible and neither is the specified scenario, because
there isn't one.
What do you mean by "neither is the specified scenario, because there
isn't one."? *Reference?
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....13d1c864883be3
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.
Do you deny using an incomplete object doesn't invoke undefined behaviour?
There is no incomplete object. You are mistaken in that.
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.
Let us take class A, you can use any method of class A in the
constructor of class A. (See "Member functions, including virtual
functions (10.3), can be called during construction or destruction")
Agreed?
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.
A thread started as the last step in the constuctor of class A can
equally well call any member of class A. Remember that by convention
(see discipline) members of class A are initialised already. If the
thead would access any object from classes other than A then obviously
those objects are constructed already otherwise the thread would not
have any reference to them.
So, where is your problem? Where are the incomplete objects?
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?
--
Ian Collins.- Hide quoted text -
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....6389deef6a40c0
Please prove that claim of yours. Nothing more, nothing less. Where is
the undefined behaviour?
Best Regards,
Szabolcs
On May 19, 11:50 am, James Kanze <james.ka...@gmail.comwrote:
On May 18, 11:00 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 18, 9:59 pm, James Kanze <james.ka...@gmail.comwrote:
On 18 mai, 18:22, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 18, 3:56 pm, James Kanze <james.ka...@gmail.comwrote:
...
The next version of the standard will definitely support threads
at the language level; that much has been pretty well proven.
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.
Very well. That explains a lot about the French contribution. You like
to talk big, don't you.
since you were trolling in the other discussion
thread in "Threading in new C++ standard" too,
....
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.
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
On 2008-04-20 12:36:50 -0400, James Kanze <james.ka...@gmail.com>
said:
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/wg...005/n1875.html.
....
</quote> http://groups.google.com/group/comp....a5fdf80fd7f461
Q.E.D.
Best Regards,
Szabolcs
On May 19, 11:22*am, James Kanze <james.ka...@gmail.comwrote:
On May 19, 9:13 am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:53**********************************@a1g2000h sb.googlegroups.com...
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created and running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
:^/
Where does the current C++ standard say that the STL is
"thread-safe to a certain extent"???
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
On May 19, 9:13*am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:53**********************************@a1g2000h sb.googlegroups.com...
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created and running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
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
On May 19, 6:42*am, Rolf Magnus <ramag...@t-online.dewrote:
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
On May 19, 6:45*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 11:50 am, James Kanze <james.ka...@gmail.comwrote:
On May 18, 11:00 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
since you were trolling in the other discussion
thread in "Threading in new C++ standard" too,
...
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.
Is it?
[...]
How about this:
<quote>
23. *Pete Becker * *View profile * More options Apr 20, 7:04 pm
On 2008-04-20 12:36:50 -0400, James Kanze <james.ka...@gmail.com>
said:
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/wg...005/n1875.html.
...
</quote>http://groups.google.com/group/comp....a5fdf80fd7f461
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.
--
gpd
On May 19, 7:14*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 6:42*am, Rolf Magnus <ramag...@t-online.dewrote:
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.
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,
--
gpd
On May 19, 7:10*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 9:13*am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:53**********************************@a1g2000h sb.googlegroups.com...
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created and running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
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
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).
--
gpd
On May 19, 8:13*pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 7:10*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 9:13*am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
>news:53**********************************@a1g2000 hsb.googlegroups.com....
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created and running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
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
Yes, in that sense is thread safe.
Please explain it to the forum fighters.
Best Regards,
Szabolcs
On May 19, 8:23*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 8:13*pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 7:10*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 9:13*am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:53**********************************@a1g2000h sb.googlegroups.com....
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created and running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
Where does the current C++ standard say that the STL is "thread-safeto 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
Yes, in that sense is thread safe.
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.
--
Giovanni P. Deretta
On May 19, 8:43*pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 8:23*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 8:13*pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 7:10*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 9:13*am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
>news:53**********************************@a1g2000 hsb.googlegroups.com...
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created andrunning
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
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
Yes, in that sense is thread safe.
Please explain it to the forum fighters.
No need. They all, especially James Kanze, know very well.
Are you suggesting that he intentionally makes fool of himself? http://groups.google.com/group/comp....81088bfec40dab
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?
Best Regards,
Szabolcs
On May 19, 9:22 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 8:43 pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 8:23 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 8:13 pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 7:10 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 9:13 am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:53**********************************@a1g2000h sb.googlegroups.com...
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created and running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
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
Yes, in that sense is thread safe.
Please explain it to the forum fighters.
No need. They all, especially James Kanze, know very well.
Are you suggesting that he intentionally makes fool of himself?http://groups.google.com/group/comp....81088bfec40dab
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.
--
gpd
darren wrote:
>
>Yes. Copying a process with fork() is very fast. You don't get much of a
performance boost from using threads.
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.
On May 19, 7:08 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 11:22 am, James Kanze <james.ka...@gmail.comwrote:
On May 19, 9:13 am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
>news:53**********************************@a1g2000 hsb.googlegroups.com....
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is created and running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
:^/
Where does the current C++ standard say that the STL is
"thread-safe to a certain extent"???
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.
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 19, 7:10 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 9:13 am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:53**********************************@a1g2000h sb.googlegroups.com...
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the STL
library).
4. Meanwhile, back at the ranch, another thread is
created and running that continuously checks for entries
into the queue.
Be aware that although STL is thread-safe to a certain extent,
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
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 19, 8:13 pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 7:10 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
[...]
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.
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 19, 9:22 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 8:43 pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 8:23 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
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.
Please explain it to the forum fighters.
No need. They all, especially James Kanze, know very well.
Are you suggesting that he intentionally makes fool of
himself?http://groups.google.com/group/comp....81088bfec40dab
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.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On May 20, 11:32*am, James Kanze <james.ka...@gmail.comwrote:
On May 19, 8:13 pm, gpderetta <gpdere...@gmail.comwrote:
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. *
As far as I can understand, a transactional memory runs under
optimistic concurrent assumptions: concurrent operations are
exectued in explicitly marked atomic blocks, and run
speculatively. At the end of the atomic block, if the system
detects that no race condition occurred, the the transaction
is allowed to commit, (i.e. its effects are made visible to
the system), else it is rolled back and optionally retried.
For example, a thread safe queue under a TM model would have
its enqueue and dequeue methods each wrapped in a atomic block.
What makes transactional memory very different from other forms
of concurrency control is composability: you can nest atomic
blocks and logically enlarge transaction scope:
tm_queue a;
tm_queue b;
atomic {
x = a.deq()
b.deq(x)
}
This block guarantees that other threads will see x in queue a OR
in queue b (never in both queues or in neither). This sort of
atomic omposability is quite a powerful abstraction which is hard
to do generically with lock based designs.
The problem of course that implementing transactional memory without
hardware support not only requires language support, but it is quite
expensive. I think that current software implementations of TM are
at most half as fast as lock based models in the non contented case.
In case of many aborts, performance can degrade quickly, so STM might
not scale very well.
So far the only system which support a form of TM in hardware are the
last SPARC systems from SUN (by sort-of-hijacking the cache coherency
protocol).
Another problem of TM is that in most practical implementations it is
possible to livelock (even if unlikely).
Real experts might be able to correct any errors in my explaination
or explain more.
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.
agree 100%
--
gpd
On May 17, 10:20 pm, darren <minof...@gmail.comwrote:
Hi
I have to write a multi-threaded program. I decided to take an OO
approach to it. I had the idea to wrap up all of the thread functions
in a mix-in class called Threadable. Then when an object should run
in its own thread, it should implement this mix-in class. Does this
sound like plausible design decision?
I'm surprised that C++ doesn't have such functionality, say in its
STL. This absence of a thread/object relationship in C++ leads me to
believe that my idea isn't a very good one.
I would appreciate your insights. thanks
We've create a framework that uses commands (GOF command pattern)
to perform inter threading communication. If the applicable
command (a member function/instance combination) is associated
with a context, it executes in that context, else it executes
in its own.
All context objects merely have on static function that
processes the next command on the queue. Application
programmers in general don't think about threading, as
it is opaque whether commands are associated with threads
or not.
In general we prevent the race conditions mentioned by
halting on a binary semaphore in the task function and
explicitly activating tasks after construction. This is
typically done by an object that is responsible for
creation of all domain objects (objects associated with
context).
Typically the context function looks like this:
int CmdMngrTaskPosix::taskEntryPoint( CmdMngrTaskPosix* inst )
{
//Wait for activation
inst->activateSem_->acquire();
inst->execState_ = eExecutionState_Activated;
while( inst->execState_ == eExecutionState_Activated )
{
inst->serviceCmdQueue();
}
//It is highly unlikely that more commands would exists
//on the queue after terminate, but flush anyway.
inst->flush();
//This is called to release the destructSem_ semaphore
// that is waiting for the task to be completed.
// destructSem_ will be acquired during either destruction
// or a call to terminateExecution().
inst->destructSem_->release();
return EXIT_SUCCESS;
}
Typically we make use of template method to create all objects,
whereafter we start tasks. Obviously tasks can be created on
the fly, but the creation and the activation is separated. Each
context (or task) has interface that allows for the mailing of
commands on its queue. Commands can consist of either member
functions or non-member functions. They are cloned prior to
mailing over queues. Arguments to the commands are stored
as pointers and usually ownership transferral occurs,
depending on the size of the argument type.
Destruction of a Context Object gets done from an orthogonal
context (typically the creator) and the destroyer is forced
to block until the context exits successfully.
All said, it's quite a large excursion to undertake, but works
quite nicely and allows the application programmer to not
think "Threads".
Regards,
Werner
On May 19, 8:01*pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 6:45*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 11:50 am, James Kanze <james.ka...@gmail.comwrote:
On May 18, 11:00 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
since you were trolling in the other discussion
thread in "Threading in new C++ standard" too,
...
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.
Is it?
[...]
How about this:
<quote>
23. *Pete Becker * *View profile * More options Apr 20, 7:04 pm
On 2008-04-20 12:36:50 -0400, James Kanze <james.ka...@gmail.com>
said:
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/wg...005/n1875.html.
...
</quote>http://groups.google.com/group/comp....a5fdf80fd7f461
Q.E.D.
Nope:
Hmmmm...
"threading API at the language level" != "threading at the language
level"
"language level" != "API"
C++ will have threading at the language level, but you will not be
able to
access the threading primitives via keywords;
Then it is not at the language level. Do you know at all what language
is?
Some of you could admit already in another discussion thread that C+
+0x does not provide threading at the language level. Check out these
questions:
1) How do you create a thread of computation in C++0x? With library
calls or at language level?
2) How do you define critical region in C++0x? With library calls or
at language level?
3) How do you let the threads of computation synchronise with each
other in C++0x? With library calls or at language level?
If you try to answer these simple questions, you might find the answer
to whether C++0x provides threading at the language level or at the
library level.
instead, you will have
to access
them through standard library based wrappers.
That is the library itself. However, your claim just means that for
the C++0x programmer threading is at the library level and not at the
language level.
As I said in the other discussion thread, there would be no problem if
you guys could admit the truth, namely, that what C++0x will provide
is nothing else but yet another threading library.
You know, calling a library API a language is dissonant.
Maybe the committee wanted to design a horse but it is going to be a
camel. A camel is beautiful creature as a camel but it is an ugly one
as a horse, and vice versa. The problem comes when you want to name a
camel a horse.
Best Regards,
Szabolcs
On May 20, 11:36*am, James Kanze <james.ka...@gmail.comwrote:
On May 19, 9:22 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 8:43 pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 8:23 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
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.
Please explain it to the forum fighters.
No need. They all, especially James Kanze, know very well.
Are you suggesting that he intentionally makes fool of
himself?http://groups.google.com/group/comp....81088bfec40dab
You ask:
Do you understand English?
I guess so.
>*The SGI statement says exactly what
I said, that the implementation is thread safe.
SGI statement simply contradicts you: "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." It is just safe for reading,
so what I said was correct that it is thread safe to a certain extent.
The SGI also confirms me: "The SGI implementation of STL is thread-
safe ONLY IN THE SENSE that ..." That is it is not "completely thread
safe" as you claimed. You like to talk big, don't you?
Now let us see what I said and what you and other mental guys with
conditioned reflex attacked like mad:
"Be aware that although STL is thread-safe to a certain extent, you
must wrap around the STL data structure to make a kind of a bounded
buffer out of it." http://groups.google.com/group/comp....50c4f92d6e0211
Besides, you still must show us how can you get elements from the
plain "completely thread safe" STL containers with multiple consumers.
(You cannot show this because you just talk big as usual.)
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.
I had a strong feeling that you have mental problem.
Best Regards,
Szabolcs
On May 20, 11:45*pm, gpderetta <gpdere...@gmail.comwrote:
think about a language like java, which has explicit
synchronized {} blocks. Certainly, by all definitions, this
is language support for threading (even if I'm sure it doesn't fit
your vision of good language threading support).
The `synchronized {} blocks' are language support for specifying
Critical Regions but, you are right, it is not correctly defined in
Java.
Let's consider a little variant of java/c++ hybrid with a
builtin mutex type, where the synchronized block take
the mutex explicitly as a parameter (instead of implicitly
like in java), and obvious semantics.
* mutex m;
* ...
* synchronized(m) {
* * *// do something in mutual exclusion
* }
So far so good.
So far not so good at all.
1) First of all the mutex is a library level tool. It is not a
language tool. It shall not appear at the language level. The mutex is
part of the library-based solution for achieving mutual exclusion of
the processes. There can be various language means for specifying
Critical Region, and one of them is the `synchronized' keyword.
However, it is not about the keyword, since you can call it
`synchronized', `region', `cr', or whatever. The main issue is that if
it is a language level means, it has consequences, see the semantics.
One important semantical issue is that the block marked by this
keyword may contain access to shared variables and access to shared
variables can only appear in these kind of blocks. Note that the low
level mutex can be inserted by the compiler to implement the Critical
Region defined at the language level. On the other hand, the high
level Critical Region can be implemented by any other means in the
compiler as far as it ensures mutual exclusion. That is one of the
benefit of a high level language.
2) In procedural languages if you introduce a keyword for a Critical
Region, you must also give some means to associate which shared
variables are involved. So, fixing your example, if there is a shared
resource `m' you can define a critical region using a keyword like
`synchronized' such as this:
shared int m; // the `shared' keyword marks the shared variable
...
synchronized(m) {
// here you can access `m'
}
Now the compiler can make sure that `m' is accessed within Critical
Regions and only within Critical Regions.
Can you see the difference between the language level means and the
library level means?
3) In object-based or higher level object-oriented languages the unit
of shared resource is obviously an object. So the association of the
Critical Region and the critical resource is naturally merged in an
object. That was one of the failure of Java that they were not brave
enough to mark the class as the shared resource. In a decent
concurrent object-oriented language you could specify a keyword for
the class to mark a shared object (and not for the methods). E.g.:
synchronized class M {
int m;
public:
void foo() {
// do something with `m' in mutual exclusion
}
};
You must mark the class as a whole and not the individual methods of
it. Then the compiler can again help you to make correct concurrent
programs. This is again not possible with library-based solution.
Note 1: We were talking about language level means for Critical Region
only but a concurrent language must provide means for Conditional
Critical Region as well. See also: http://groups.google.com/group/comp....1b2d8d13869371
Note 2: There is an important issue of defining threads of computation
at the language level, and the object-oriented solution for it is
indicated in the title of this discussion thread: "What's the
connection between objects and threads?" See also: http://groups.google.com/group/comp....99fb9fb8c3a42a
Best Regards,
Szabolcs
On Tue, 20 May 2008 16:34:04 -0700, Szabolcs Ferenczi wrote:
2) In procedural languages if you introduce a keyword for a Critical
Region, you must also give some means to associate which shared
variables are involved. So, fixing your example, if there is a shared
resource `m' you can define a critical region using a keyword like
`synchronized' such as this:
shared int m; // the `shared' keyword marks the shared variable ...
synchronized(m) {
// here you can access `m'
}
Now the compiler can make sure that `m' is accessed within Critical
Regions and only within Critical Regions.
Can you see the difference between the language level means and the
library level means?
Lets imagine, instead of your syntax, we use this syntax:
shared<intm;
{
synchronized<ints(m);
// Here you can access the shared int 'm' through the object 's'
}
Again, the compiler can ensure that the shared state is only accessed
within a critical region (which, in this case, is equivalent to a block
containing the construction of the relevant synchronized<Tobject). But
my proposed syntax can be implemented just as well with a library
solution as with a keyword based one, if the language provides certain
guarantees. So what's the difference?
On May 21, 2:26*am, I V <ivle...@gmail.comwrote:
On Tue, 20 May 2008 16:34:04 -0700, Szabolcs Ferenczi wrote:
2) In procedural languages if you introduce a keyword for a Critical
Region, you must also give some means to associate which shared
variables are involved. So, fixing your example, if there is a shared
resource `m' you can define a critical region using a keyword like
`synchronized' such as this:
shared int m; * * // the `shared' keyword marks the shared variable ....
synchronized(m) {
* // here you can access `m'
}
Now the compiler can make sure that `m' is accessed within Critical
Regions and only within Critical Regions.
Can you see the difference between the language level means and the
library level means?
Lets imagine, instead of your syntax, we use this syntax:
shared<intm;
{
* * * * synchronized<ints(m);
* * * * // Here you can access the shared int 'm' through the object 's'
}
Again, the compiler can ensure that the shared state is only accessed
within a critical region (which, in this case, is equivalent to a block
containing the construction of the relevant synchronized<Tobject). But
my proposed syntax can be implemented just as well with a library
solution as with a keyword based one, if the language provides certain
guarantees. So what's the difference?
It is not about syntax but first of all it is about semantics.
However, without syntax you cannot talk about semantics.
In your version `shared' and `synchronized' are keywords, aren't
they?
If yes, you already introduced keywords for the language which the
compiler can recognise. How would you describe the semantics of these
keywords? What is the role of object `s'?
If not, it can really be implemented with a library solution but the
compiler will not be able to identify the block what you mean as the
Critical Region and hence it cannot ensure for you that the intended
shared variable is only accessed within Critical Region.
Is it clear to you?
(Note that the role of "object 's'" is not clear in your proposal, see
"the shared int 'm' through the object 's'".)
Best Regards,
Szabolcs
On May 20, 5:34*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 20, 11:45*pm, gpderetta <gpdere...@gmail.comwrote:
think about a language like java, which has explicit
synchronized {} blocks. Certainly, by all definitions, this
is language support for threading (even if I'm sure it doesn't fit
your vision of good language threading support).
The `synchronized {} blocks' are language support for specifying
Critical Regions but, you are right, it is not correctly defined in
Java.
Let's consider a little variant of java/c++ hybrid with a
builtin mutex type, where the synchronized block take
the mutex explicitly as a parameter (instead of implicitly
like in java), and obvious semantics.
* mutex m;
* ...
* synchronized(m) {
* * *// do something in mutual exclusion
* }
So far so good.
So far not so good at all.
1) First of all the mutex is a library level tool. It is not a
language tool. It shall not appear at the language level. The mutex is
part of the library-based solution for achieving mutual exclusion of
the processes. There can be various language means for specifying
Critical Region, and one of them is the `synchronized' keyword.
However, it is not about the keyword, since you can call it
`synchronized', `region', `cr', or whatever. The main issue is that if
it is a language level means, it has consequences, see the semantics.
One important semantical issue is that the block marked by this
keyword may contain access to shared variables and access to shared
variables can only appear in these kind of blocks. Note that the low
level mutex can be inserted by the compiler to implement the Critical
Region defined at the language level. On the other hand, the high
level Critical Region can be implemented by any other means in the
compiler as far as it ensures mutual exclusion. That is one of the
benefit of a high level language.
2) In procedural languages if you introduce a keyword for a Critical
Region, you must also give some means to associate which shared
variables are involved. So, fixing your example, if there is a shared
resource `m' you can define a critical region using a keyword like
`synchronized' such as this:
shared int m; * * // the `shared' keyword marks the shared variable
...
synchronized(m) {
* // here you can access `m'
}
Now the compiler can make sure that `m' is accessed within Critical
Regions and only within Critical Regions.
Can you see the difference between the language level means and the
library level means?
3) In object-based or higher level object-oriented languages the unit
of shared resource is obviously an object. So the association of the
Critical Region and the critical resource is naturally merged in an
object. That was one of the failure of Java that they were not brave
enough to mark the class as the shared resource. In a decent
concurrent object-oriented language you could specify a keyword for
the class to mark a shared object (and not for the methods). E.g.:
synchronized class M {
* int m;
public:
* void foo() {
* * // do something with `m' in mutual exclusion
* }
};
You must mark the class as a whole and not the individual methods of
it. Then the compiler can again help you to make correct concurrent
programs. This is again not possible with library-based solution.
I'm not sure marking the class like that is a good idea. Would you
mark vector as synchronized? If yes, do you expect compilers to
figure
out that only one thread is able to access some of your vector objects
at
any point in time and disable the synchronization? I don't want to
pay for
extra synchronization when it isn't needed.
Brian Wood
Ebenezer Enterprises www.webEbenezer.net
On Tue, 20 May 2008 17:56:10 -0700, Szabolcs Ferenczi wrote:
On May 21, 2:26Â*am, I V <ivle...@gmail.comwrote:
>Again, the compiler can ensure that the shared state is only accessed
within a critical region (which, in this case, is equivalent to a block
containing the construction of the relevant synchronized<Tobject).
But my proposed syntax can be implemented just as well with a library
solution as with a keyword based one, if the language provides certain
guarantees. So what's the difference?
It is not about syntax but first of all it is about semantics. However,
without syntax you cannot talk about semantics.
Sure; I was trying to show you that you could get identical semantics to
the ones in your example using the existing C++ syntax (clearly, you need
more semantics than the C++ standard currently specifies; but the point
is that you don't need any more syntax).
In your version `shared' and `synchronized' are keywords, aren't they?
They don't have to be, that's the point. They could be class templates.
If yes, you already introduced keywords for the language which the
compiler can recognise. How would you describe the semantics of these
keywords? What is the role of object `s'?
With your suggestion, you declare the shared int 'm', synchronize on that
variable 'm', and access the shared data through the object 'm'. In my
suggestion, you declare the shared int 'm' and synchronize on the
variable 'm', but you access the shared data through the variable 's'.
The object of type synchronized<Tprovides access to shared data of type
T that was declared with shared<T>. When an object of type
synchronized<Tis created, it ensures (through whatever method - the
obvious one is a mutex) that any other attempt to created a
synchronized<Tbased on the particular shared variable will block. When
the synchronized<Tis destroyed, it removes that restriction.
If not, it can really be implemented with a library solution but the
compiler will not be able to identify the block what you mean as the
Critical Region and hence it cannot ensure for you that the intended
shared variable is only accessed within Critical Region.
Sure it can. The point is that the object of type synchronized<Tis the
only way in which one can gain access to the shared data. Therefore,
anywhere in which an object of type synchronized<Tis in scope is a
critical region; any attempt to access the shared state without creating
a synchronized<Tobject (and therefore a critical region) will cause a
compile error. For instance:
shared<inti, j, k;
i = j + k;
wouldn't compile, whereas:
shared<inti, j, k;
{
synchronized<ints_i(i), s_j(j), s_k(k);
s_i = s_j + s_k
}
would.
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:ed**********************************@d45g2000 hsc.googlegroups.com...
On May 19, 5:16 am, Ian Collins <ian-n...@hotmail.comwrote:
[...]
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....6389deef6a40c0
Please prove that claim of yours. Nothing more, nothing less. Where is
the undefined behaviour?
I already showed a code example.
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:bd**********************************@a1g2000h sb.googlegroups.com...
On May 19, 8:54 am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:f9**********************************@2g2000hs n.googlegroups.com...
On May 18, 3:23 pm, James Kanze <james.ka...@gmail.comwrote:
Except that, as Chris has already pointed out, it results in a
race condition. It's a serious design error.
Well, he did not point out anything but claimed something. He has
postings that he used to correct the next hour or the next day.
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...
You better read carefully what I have written. I highlighted that one
needs discipline for it. It is hopless for you but at least you calm
down.
I hope I could help though.
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:
__________________________________________________ __________________
[...]
__________________________________________________ __________________
The above demonstrates ...
Well, the above demonstrates that a hacker can misuse any formal
system.
The above demonstrates one reason why its generally NOT a good idea to start
threads in ctors.
Kurt Goedel can be very pleased now up there since slaves are working
for him down here.
Congratulations!
Huh?
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:41**********************************@24g2000h sh.googlegroups.com...
On May 19, 9:13 am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:53**********************************@a1g2000h sb.googlegroups.com...
On May 18, 11:43 am, darren <minof...@gmail.comwrote:
3. A successful accepted connection is put into a queue (from the
STL
library).
4. Meanwhile, back at the ranch, another thread is created and
running
that continuously checks for entries into the queue.
Be aware that although STL is thread-safe to a certain extent,
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
I specifically asked about the C++ Standard. I am really not interested in a
particular vendors implementation. Try again...
"gpderetta" <gp*******@gmail.comwrote in message
news:be**********************************@u6g2000p rc.googlegroups.com...
On May 20, 9:26 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
>On May 19, 8:01 pm, gpderetta <gpdere...@gmail.comwrote:
On May 19, 6:45 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 19, 11:50 am, James Kanze <james.ka...@gmail.comwrote:
On May 18, 11:00 pm, Szabolcs Ferenczi
<szabolcs.feren...@gmail.com>
wrote:
since you were trolling in the other discussion
thread in "Threading in new C++ standard" too,
...
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.
Is it?
[...]
How about this:
<quote>
23. Pete Becker View profile More options Apr 20, 7:04 pm
On 2008-04-20 12:36:50 -0400, James Kanze <james.ka...@gmail.com>
said:
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/wg...005/n1875.html.
...
</quote>http://groups.google.com/group/comp....a5fdf80fd7f461
Q.E.D.
Nope:
Hmmmm...
"threading API at the language level" != "threading at the language
level"
"language level" != "API"
C++ will have threading at the language level, but you will not be
able to
access the threading primitives via keywords;
Then it is not at the language level. Do you know at all what language
is?
*sigh*. We have been trying to explain it painfully to you for a long
time.
[...]
Well, at this point, IMVHO, Szabolcs has rendered himself into a complete
troll with no intention on learning anything. He even called David Butenhof
a fool for patiently trying to explain to him that condvars can be used to
signal about events that result from state mutations. Szabolcs makes an
assertion on comp.programming.threads that condvars CANNOT be used to signal
events; David Butenhof comes to his aid and tries to educate him, and ends
up getting called a fool... AFAICT, Szabolcs does not get it. Or, he does
not want to get it... Or, perhaps he does get it, and enjoys making an a$s
out of himself anyway. I am not entirely sure which one is correct...
I agree with James Kanze in that there should be a correcting response to
Szabolcs misleading and/or complete false claims just for the sake of some
newbie that might be mislead...
:^/
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:74**********************************@f63g2000 hsf.googlegroups.com...
On May 19, 11:50 am, James Kanze <james.ka...@gmail.comwrote:
>On May 18, 11:00 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 18, 9:59 pm, James Kanze <james.ka...@gmail.comwrote:
On 18 mai, 18:22, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On May 18, 3:56 pm, James Kanze <james.ka...@gmail.comwrote:
...
The next version of the standard will definitely support threads
at the language level; that much has been pretty well proven.
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.
Very well. That explains a lot about the French contribution.
[...]
That's it... Insult an entire nation! Wow.
You like to talk big, don't you.
IMVHO, James Kanze gives great advise. However, you seem to "enjoy" talking
down to experienced people from a position of high "ignorance". Sorry, but
that's the way you come across Sir.
:^|
Chris Thomasson wrote:
>
Well, at this point, IMVHO, Szabolcs has rendered himself into a
complete troll with no intention on learning anything.
Yet we still keep feeding him...
He even called
David Butenhof a fool for patiently trying to explain to him that
condvars can be used to signal about events that result from state
mutations.
Now that was a classic. The put down was even better: http://tinyurl.com/5wk4l6
I should have learned my lesson there.
--
Ian Collins.
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:de**********************************@t54g2000 hsg.googlegroups.com...
On May 19, 1:41 am, Ian Collins <ian-n...@hotmail.comwrote:
Szabolcs Ferenczi wrote:
What is your problem exactly? It would be good, if instead of trolling
you would prove something finally.
I see your true colours have finally come through, insult all who
disagree with you.
I try to get some proof out of you instead of you keep trolling.
Besides, I new you would escape instead of proving your claims. It is
the nature of trollers.
Ian already tried to patiently explain why running threads from ctors can be
a bad idea. I even gave you some code which shows how undefined behavior
results when a pure virtual function is invoked from the ctor of a base
class! Why is that so hard to understand Szabolcs? Did you know that the OP
was thinking about creating a thread object that was going to be used as a
base class? Your comment which suggested that creating threads in ctors is
okay was down right dangerous when you take the OP's question into account!
Why do you get angry when somebody points out one of your mistakes? You
should be thanking them for taking the time to do so!
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:ab**********************************@56g2000h sm.googlegroups.com...
On May 19, 6:42 am, Rolf Magnus <ramag...@t-online.dewrote:
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.
Name a platform?
Chris Thomasson wrote:
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:de**********************************@t54g2000 hsg.googlegroups.com...
>On May 19, 1:41 am, Ian Collins <ian-n...@hotmail.comwrote:
Szabolcs Ferenczi wrote:
What is your problem exactly? It would be good, if instead of
trolling
you would prove something finally.
I see your true colours have finally come through, insult all who
disagree with you.
>I try to get some proof out of you instead of you keep trolling.
>Besides, I new you would escape instead of proving your claims. It is
the nature of trollers.
Ian already tried to patiently explain why running threads from ctors
can be a bad idea.
I should add that I didn't "escape", I just realised my head would loose
out to the brick wall.
--
Ian Collins.
On May 21, 6:39*am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:de**********************************@t54g2000 hsg.googlegroups.com...
On May 19, 1:41 am, Ian Collins <ian-n...@hotmail.comwrote:
Szabolcs Ferenczi wrote:
What is your problem exactly? It would be good, if instead of trolling
you would prove something finally.
I see your true colours have finally come through, insult all who
disagree with you.
I try to get some proof out of you instead of you keep trolling.
Besides, I new you would escape instead of proving your claims. It is
the nature of trollers.
Your claim:
Ian already tried to patiently explain why running threads from ctors can be
a bad idea.
On the contrary I was patiently correct all his mistakes. The last
time in this post: http://groups.google.com/group/comp....2557fe9a4b7909
Then he failed as I predicted.
I even gave you some code which shows how undefined behavior
results when a pure virtual function is invoked from the ctor of a base
class!
I made the remark to your the relevant piece of hack that it is a
clear example to the fact that hackers can misuse any formal notation. http://groups.google.com/group/comp....d8850e3ec7ab3a
You misused C++ in a sequential mode in your demonstration.
Best Regards,
Szabolcs This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Rob Nicholson |
last post by:
I'm starting to worry a bit now. We're getting the above error when two
users hit the same database/page on an ASP.NET application using ADO.NET,
talking to a SQL 7 server. The error is perfectly...
|
by: Lau Lei Cheong |
last post by:
Hello,
Actually I think I should have had asked it long before, but somehow
I haven't.
Here's the scenerio: Say we have a few pages in an ASP.NET project,
each of them needs to connect to...
|
by: nephish |
last post by:
hey there,
i have a huge app that connects to MySQL. There are three threads that
are continually connecting and disconnecting to the db. The problem is,
if there is an error, it faults out...
|
by: Steven Blair |
last post by:
As I understand it, if I create a connection object in my application
and close the connection, the next time I open a connection with the
same connection string I should be using a pooled...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
| |
