Mutex/Lock

[Chris Forone]

hello group,

is there a chance for other functions to get the lock if i have
following loop:

while (running)
{
Lock local(mutex);
}

if not, is it enough to change scope:

while (running)
{
{
Lock local(mutex);
}
}

thanx & hand, chris

[Gianni Mariani]

Chris Forone wrote:

hello group,

is there a chance for other functions to get the lock if i have
following loop:

while (running)
{
Lock local(mutex);
}

yes - that code is the same as

while (running) {
mutex.lock();
mutex.unlock();
}

>
if not, is it enough to change scope:

while (running)
{
{
Lock local(mutex);
}
}

Makes no difference.

[Paul Brettschneider]

Chris Forone wrote:

hello group,

is there a chance for other functions to get the lock if i have
following loop:

while (running)
{
Lock local(mutex);
}

if not, is it enough to change scope:

while (running)
{
{
Lock local(mutex);
}
}

You probably want:

{
Lock local(mutex);
while(running)
{
...
}
}

[Chris Thomasson]

"Paul Brettschneider" <pa*****************@yahoo.frwrote in message
news:92**************************@news.chello.at.. .

Chris Forone wrote:

>hello group,

is there a chance for other functions to get the lock if i have
following loop:

while (running)
{
Lock local(mutex);
}

if not, is it enough to change scope:

while (running)
{
{
Lock local(mutex);
}
}

You probably want:

{
Lock local(mutex);
while(running)
{
...
}
}

Why?

[Chris Thomasson]

"Gianni Mariani" <gi*******@mariani.wswrote in message
news:48********@news.mel.dft.com.au...

Chris Forone wrote:

>hello group,

is there a chance for other functions to get the lock if i have following
loop:

while (running)
{
Lock local(mutex);
}

yes - that code is the same as

while (running) {
mutex.lock();
mutex.unlock();
}

You mean that code is the same as:
while (running) {
try {
mutex.lock();
} catch (...) {
mutex.unlock();
throw;
}
mutex.unlock();
}
Right?
[...]

[Chris Forone]

Paul Brettschneider schrieb:

Chris Forone wrote:

>hello group,

is there a chance for other functions to get the lock if i have
following loop:

while (running)
{
Lock local(mutex);
}

if not, is it enough to change scope:

while (running)
{
{
Lock local(mutex);
}
}

You probably want:

{
Lock local(mutex);
while(running)
{
...
}
}

No, the first version is the one i need. its to suspend/resume in a well
defined position in code. So i had:

bool Resume()
{
Lock local(mutex);
// resume thread
}

bool Suspend()
{
Lock local(mutex);
// suspend thread
}

bool Exit()
{
Lock local(mutex);
// here was my dl, because of wait for thread termination :-)
}

void Proc()
{
while (active)
{
Lock local(mutex);
// do things
}
}

now my Exit looks:

bool Exit()
{
mutex.Acquire();

if (active)
{
active = false, mutex.Release();
// wait for thread termination :-)))
}

mutex.Release();
}

it functs, hope it is waterproof...

thanks & hand, chris

ps: Ideas for better doing it are very welcome!

[Chris Forone]

Errata:

bool Exit()
{
mutex.Acquire();

if (active)
{
active = false;
mutex.Release();
// wait for thread termination :-)))
}

mutex.Release();
}

if i write:

active = false, mutex.Release()

i think, the mutex is first released -error

is this right?

thanx & hand, chris

[Paul Brettschneider]

Chris Forone wrote:

Paul Brettschneider schrieb:

>Chris Forone wrote:

>>hello group,

is there a chance for other functions to get the lock if i have
following loop:

while (running)
{
Lock local(mutex);
}

if not, is it enough to change scope:

while (running)
{
{
Lock local(mutex);
}
}

You probably want:

{
Lock local(mutex);
while(running)
{
...
}
}

No, the first version is the one i need. its to suspend/resume in a well
defined position in code. So i had:

Ah. I misread your question. I think what you want is a notify/signal
mechanism, which should be implemented for every thread package. (In
pthreads it's the pthread_cond_* functions.)

[James Kanze]

On May 31, 10:39 am, Chris Forone <[e-mail]:

Errata:

bool Exit()
{
mutex.Acquire();

if (active)
{
active = false;
mutex.Release();
// wait for thread termination :-)))
}

mutex.Release();
}

if i write:

active = false, mutex.Release()

i think, the mutex is first released -error

is this right?

No. There's a sequence point at the comma, so all side effects
of the preceding expression must be finished before any side
effects of the following occur.

I do wonder about your code, however. You really need to
recover the mutex before the end of the if---otherwise, you'll
release it twice. And how do you wait for thread termination:
with a join, or with some sort of global thread counter? In the
latter case, you'll need the mutex to read it as well.

I generally use something like:

void
requestTermination()
{
ScopedLock lock( terminateFlagMutex ) ;
terminateRequested = true ;
}

void
waitForAllThreadsToTerminate()
{
ScopedLock lock( threadCountMutex ) ;
while ( threadCount != 0 ) {
threadCountCondition.wait( lock ) ;
}
}

void
terminate()
{
requestTermination() ;
waitForAllThreadsToTerminate() ;
}

with:

void
endOfThread()
{
ScopedLock lock( threadCountMutex ) ;
-- threadCount ;
threadCountCondition.notify() ;
}

at the end of each thread. (Note that this does require some
care when starting threads, since a race condition can occur
there if you're not careful. In my case, it's not a problem,
because all of the threads are always started by the main
thread, which is also the only thread which will call
terminate(), but if other running threads might start a thread
while you're calling terminate, you'll have to add some
additional logic in thread start-up to avoid the race.)

--
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, [phone]

[Chris Forone]

James Kanze schrieb:

On May 31, 10:39 am, Chris Forone <[e-mail]:

>Errata:

>bool Exit()
{
mutex.Acquire();

> if (active)
{
active = false;
mutex.Release();
// wait for thread termination :-)))
}

> mutex.Release();
}

>if i write:

>active = false, mutex.Release()

>i think, the mutex is first released -error

>is this right?

No. There's a sequence point at the comma, so all side effects
of the preceding expression must be finished before any side
effects of the following occur.

I do wonder about your code, however. You really need to
recover the mutex before the end of the if---otherwise, you'll
release it twice. And how do you wait for thread termination:
with a join, or with some sort of global thread counter? In the
latter case, you'll need the mutex to read it as well.

Thanx for the example. The wait is done with the win32 function
WaitForSingleObject() with no timeout. Excuse me for the incomplete example:

bool Exit()
{
mutex.Acquire();

if (active)
{
active = false;
mutex.Release();

return WaitForSingleObject(thread, INFINITE) == WAIT_OBJECT_0;
}

mutex.Release();
}

The sideeffect-thing i dont understand...

What about:

return someVar1 == 10 &&
someVar2 != 20 &&
(someVar3 = someFunc()) == true;

and

return (someVar1 == 10) &&
(someVar2 != 20) &&
(someVar3 = someFunc()) == true;

thanx & hand, chris

[jason.cipriani]

On May 31, 4:21 am, Chris Forone <[e-mail]:

No, the first version is the one i need. its to suspend/resume in a well
defined position in code. So i had:

bool Resume()

bool Suspend()

bool Exit()

void Proc()

bool Exit()
{
mutex.Acquire();

if (active)
{
active = false, mutex.Release();
// wait for thread termination :-)))
}

mutex.Release();

}

ps: Ideas for better doing it are very welcome!

Chris,

It's funny I just implemented almost exactly the same thing. A thread
with Start, Stop, Suspend, and Resume, although in my case I implement
"Start" and "Resume" with the same function. I have been having good
results with this. I use two mutices; one for the thread handles
themselves, and another for the "suspend" flag. You may find this
unnecessary, but in my actual application the "suspend" flag mutex
protects many other things (it is a media playback application of
sorts that maintains a number of other timing related parameters as
well). Note that this isn't real C++:

====================

// threadmtx has default spin count of 0, suspendmtx set at 3000.
CRITICAL_SECTION threadmtx, suspendmtx;
HANDLE hthread = NULL;
bool paused = false;
bool quitflag = false;

Start () {

// Resume thread if it's suspended.
Lock suspendmtx;
paused = false;
Unlock suspendmtx;

// Start thread if it's not running.
Lock threadmtx;
if (hthread == NULL) {
quitflag = false;
hthread = CreateThread(..., Proc, ...);
}
Unlock threadmtx;

}

Suspend () {

// Pause thread.
Lock suspendmtx;
paused = true;
Unlock suspendmtx;

}

Stop () {

// stop thread if it's running
Lock threadmtx;
if (hthread != NULL) {
quitflag = true;
if (WaitForSingleObject(hthread, timeout) == WAIT_TIMEOUT)
TerminateThread(hthread); // sholdn't happen
CloseHandle(hthread);
hthread = NULL;
}
Unlock threadmtx;

}

Proc () {

bool ispaused = false, pausing, unpausing;

// loop until asked to quit
while (!quitflag) {

Lock suspendmtx;
pausing = paused && !ispaused;
unpausing = ispaused && !paused;
ispaused = paused;
Unlock suspendmtx;

if (pausing) {
// do anything you want to do when thread transitions to paused
} else if (unpausing) {
// do anything you want to do when thread transitions to
unpaused
}

if (paused) {
Sleep(10); // or whatever
continue;
}

do normal processing here;

}

}

==== END EXAMPLE ====

Again, apologies for the strange looking example, I pieced it together
in this email from a slightly more complex piece of code. The pausing/
unpausing logic isn't necessary for anything but it lets you do things
when the thread state changes, if you want, I thought I'd throw that
in there. Hopefully it makes sense.

In my case I made a slight trade-off of added code simplicity at the
expense of niceness. The "if (paused) { Sleep(10); continue; }" is the
culprit there. You may instead want to do something like "if (paused)
{ WaitForSingleObject(unpausedevent); }" and SetEvent(unpausedevent)
when you unpause the thread, that way it will sleep until you resume
it rather than looping and waiting.

You could also use SuspendThread/ResumeThread, depending on your
requirements. However, I am not sure where those functions actually
suspend the thread -- I don't know if Windows has a concept of
"suspend points" or if it just stops the thread right where it is in a
potentially unsafe place (for example, in the middle of a critical
section, or in the middle of sending data to an external hardware
device or whatever it is your thread does).

Jason

[Gianni Mariani]

Chris Thomasson wrote:

You mean that code is the same as:

....

My mutex mutex.lock() does not throw.

[James Kanze]

On May 31, 12:20 pm, Chris Forone <[e-mail]:

James Kanze schrieb:

[...]

Thanx for the example. The wait is done with the win32 function
WaitForSingleObject() with no timeout.

That is, I think, a join.

Windows is noted for using non-standard terminology, although in
this case, it might be justified. Still, if there is a function
which will insist that the handle refers to a thread, and return
an error if it doesn't, I'd use that. Static typing is
significantly more robust than dynamic typing.

Excuse me for the incomplete example:

bool Exit()
{
mutex.Acquire();

if (active)
{
active = false;
mutex.Release();

return WaitForSingleObject(thread, INFINITE) == WAIT_OBJECT_0;
}
mutex.Release();

This call will fail (probably with an assertion failure, if the
Mutex class is well written) if the condition for the if is
true.

}

The side effect-thing i dont understand...

What about:

return someVar1 == 10 &&
someVar2 != 20 &&
(someVar3 = someFunc()) == true;

&& and || are also sequence points. But I'd never write code
like that, with a change of state hidden down in the middle of a
complicated expression, where it won't be easily seen. Nor
would I compare with true: if someVar3 has type bool, then
that's what you need, and no comparison is necessary, and if it
doesn't, I'd write the comparison to compare with something of
whatever type it has.

and

return (someVar1 == 10) &&
(someVar2 != 20) &&
(someVar3 = someFunc()) == true;

Parentheses don't change anything.

--
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, [phone]

[Chris Thomasson]

"Gianni Mariani" <gi*******@mariani.wswrote in message
news:48******@news.mel.dft.com.au...

Chris Thomasson wrote:

>You mean that code is the same as:

ACK! I should of said:

while (running) {
try {
mutex.lock();
[critical-section];
} catch (...) {
mutex.unlock();
throw;
}
mutex.unlock();
}

My mutex mutex.lock() does not throw.

How do you report locking errors? Do you just call `std::unexpected()' or
`std::abort()'? For instance, on Windows, how do you handle
`WAIT_ABANDONED'? Or when `pthread_mutex_lock()' returns `EINVAL' due to a
priority violation?

http://groups.google.com/group/comp....806366efcaaae6

[Gianni Mariani]

Chris Thomasson wrote:
....

How do you report locking errors? Do you just call `std::unexpected()'
or `std::abort()'? For instance, on Windows, how do you handle
`WAIT_ABANDONED'? Or when `pthread_mutex_lock()' returns `EINVAL' due to
a priority violation?

Abort.
http://austria.svn.sourceforge.net/v...w=markup#l_371

I consider it a serious programming error.

[Chris Thomasson]

"Gianni Mariani" <gi*******@mariani.wswrote in message
news:48********@news.mel.dft.com.au...

Chris Thomasson wrote:
...

>How do you report locking errors? Do you just call `std::unexpected()' or
`std::abort()'? For instance, on Windows, how do you handle
`WAIT_ABANDONED'? Or when `pthread_mutex_lock()' returns `EINVAL' due to
a priority violation?

Abort.
http://austria.svn.sourceforge.net/v...w=markup#l_371

I consider it a serious programming error.

Fair enough. However, `WAIT_ABANDONED' can be a legitimate error to receive
on lock acquisition. How do you handle that scenario? I am not sure that
throwing would be the best solution. Perhaps something like this would be
better:
class process_wide_mutex {
HANDLE m_mtx;

public:
typedef void (fp_recover_type) ();

void lock(fp_recover_type* const fp_recover = NULL) {
DWORD CONST status = WaitForSingleObject(m_mtx, INFINITE);
if (status != WAIT_OBJECT_0) {
if (status != WAIT_ABANDONED || ! fp_recover) {
assert(false);
std::unexpected();
}
fp_recover();
}
}

[...];
};
What do you think?

[Chris Forone]

James Kanze schrieb:

On May 31, 12:20 pm, Chris Forone <[e-mail]:

>James Kanze schrieb:

[...]

>Thanx for the example. The wait is done with the win32 function
WaitForSingleObject() with no timeout.

That is, I think, a join.

Windows is noted for using non-standard terminology, although in
this case, it might be justified. Still, if there is a function
which will insist that the handle refers to a thread, and return
an error if it doesn't, I'd use that. Static typing is
significantly more robust than dynamic typing.

>Excuse me for the incomplete example:

>bool Exit()
{
mutex.Acquire();

> if (active)
{
active = false;
mutex.Release();

> return WaitForSingleObject(thread, INFINITE) == WAIT_OBJECT_0;
}
mutex.Release();

This call will fail (probably with an assertion failure, if the
Mutex class is well written) if the condition for the if is
true.

>}

>The side effect-thing i dont understand...

>What about:

>return someVar1 == 10 &&
someVar2 != 20 &&
(someVar3 = someFunc()) == true;

&& and || are also sequence points. But I'd never write code
like that, with a change of state hidden down in the middle of a
complicated expression, where it won't be easily seen. Nor
would I compare with true: if someVar3 has type bool, then
that's what you need, and no comparison is necessary, and if it
doesn't, I'd write the comparison to compare with something of
whatever type it has.

>and

>return (someVar1 == 10) &&
(someVar2 != 20) &&
(someVar3 = someFunc()) == true;

Parentheses don't change anything.

--
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, [phone]

Tanks a lot! Chris

[Chris Forone]

ja************@gmail.com schrieb:

It's funny I just implemented almost exactly the same thing. A thread
with Start, Stop, Suspend, and Resume, although in my case I implement
"Start" and "Resume" with the same function. I have been having good
results with this. I use two mutices; one for the thread handles
themselves, and another for the "suspend" flag. You may find this
unnecessary, but in my actual application the "suspend" flag mutex
protects many other things (it is a media playback application of
sorts that maintains a number of other timing related parameters as
well). Note that this isn't real C++:

====================

// threadmtx has default spin count of 0, suspendmtx set at 3000.
CRITICAL_SECTION threadmtx, suspendmtx;
HANDLE hthread = NULL;
bool paused = false;
bool quitflag = false;

Start () {

// Resume thread if it's suspended.
Lock suspendmtx;
paused = false;
Unlock suspendmtx;

// Start thread if it's not running.
Lock threadmtx;
if (hthread == NULL) {
quitflag = false;
hthread = CreateThread(..., Proc, ...);
}
Unlock threadmtx;

}

Suspend () {

// Pause thread.
Lock suspendmtx;
paused = true;
Unlock suspendmtx;

}

Stop () {

// stop thread if it's running
Lock threadmtx;
if (hthread != NULL) {
quitflag = true;
if (WaitForSingleObject(hthread, timeout) == WAIT_TIMEOUT)
TerminateThread(hthread); // sholdn't happen
CloseHandle(hthread);
hthread = NULL;
}
Unlock threadmtx;

}

Proc () {

bool ispaused = false, pausing, unpausing;

// loop until asked to quit
while (!quitflag) {

Lock suspendmtx;
pausing = paused && !ispaused;
unpausing = ispaused && !paused;
ispaused = paused;
Unlock suspendmtx;

if (pausing) {
// do anything you want to do when thread transitions to paused
} else if (unpausing) {
// do anything you want to do when thread transitions to
unpaused
}

if (paused) {
Sleep(10); // or whatever
continue;
}

do normal processing here;

}

}

==== END EXAMPLE ====

Again, apologies for the strange looking example, I pieced it together
in this email from a slightly more complex piece of code. The pausing/
unpausing logic isn't necessary for anything but it lets you do things
when the thread state changes, if you want, I thought I'd throw that
in there. Hopefully it makes sense.

In my case I made a slight trade-off of added code simplicity at the
expense of niceness. The "if (paused) { Sleep(10); continue; }" is the
culprit there. You may instead want to do something like "if (paused)
{ WaitForSingleObject(unpausedevent); }" and SetEvent(unpausedevent)
when you unpause the thread, that way it will sleep until you resume
it rather than looping and waiting.

You could also use SuspendThread/ResumeThread, depending on your
requirements. However, I am not sure where those functions actually
suspend the thread -- I don't know if Windows has a concept of
"suspend points" or if it just stops the thread right where it is in a
potentially unsafe place (for example, in the middle of a critical
section, or in the middle of sending data to an external hardware
device or whatever it is your thread does).

Jason

Thanks for the example. In my case its an "active object" as a timer.
The sync is for a "suspend point" (you said), to Resume/Suspend in a
well defined section. The approach with thread creation at first Start()
i can use eventually, i create the thread in ctor w/ CREATE_SUSPENDED,
saw in the web, create thread in ctor is evil...

Greetings & hand, Chris

[Chris Thomasson]

"Chris Forone" <4o**@gmx.atwrote in message
news:g1**********@newsreader2.utanet.at...
[...\]

Thanks for the example. In my case its an "active object" as a timer. The
sync is for a "suspend point" (you said), to Resume/Suspend in a well
defined section. The approach with thread creation at first Start() i can
use eventually, i create the thread in ctor w/ CREATE_SUSPENDED, saw in
the web, create thread in ctor is evil...

[...]

Creating threads in a ctor is generally considered evil indeed. However,
starting threads(s) in ctors which act on
___fully___constructed___object(s)___ is NOT! Case in point:

http://groups.google.com/group/comp....c14991f9e88482

Any thoughts?

[Szabolcs Ferenczi]

On Jun 1, 10:26*am, "Chris Thomasson" <[e-mail]:

"Chris Forone" <[e-mail] in message

news:g1**********@newsreader2.utanet.at...
[...\]Thanks for the example. In my case its an "active object" as a timer. The

sync is for a "suspend point" (you said), to Resume/Suspend in a well
defined section. The approach with thread creation at first Start() i can
use eventually, i create the thread in ctor w/ CREATE_SUSPENDED, saw in
the web, create thread in ctor is evil...

[...]

Creating threads in a ctor is generally considered evil indeed. However,
starting threads(s) in ctors which act on
___fully___constructed___object(s)___ is NOT! Case in point:

http://groups.google.com/group/comp....c14991f9e88482

Any thoughts?

As for one remark, you and your enthusiastic friend tried really hard
but finally you could not prove or demonstrate that starting a thread
as the last step in the constructor could result in any problem
provided one is disciplined enough. In fact I have deduced it from the
text of the standard that nothing forbids it.

Second, you yourself solved your own problem or doubt by simply
providing a wrapper template (see your own link).

Third, the concept of _active object_ is a well known concept in
computer science except for in the circles of C++ hackers.

I hope this helps.

Best Regards,
Szabolcs

[James Kanze]

On May 31, 10:39 am, Chris Forone <[e-mail]:

Errata:

bool Exit()
{
mutex.Acquire();

if (active)
{
active = false;
mutex.Release();
// wait for thread termination :-)))
}

mutex.Release();

You're still releasing the mutex twice if active is initially
true. Which could cause an assertion failure.

}

if i write:

active = false, mutex.Release()

i think, the mutex is first released -error

is this right?

No. Assignment has higher precedence than the comma operator,
so this is the equivalent of:

(active = false), (mutex.Release()) ;

Still, it's something I would avoid at all costs, for reasons of
readability.

--
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, [phone]

[Gianni Mariani]

Chris Thomasson wrote:

"Gianni Mariani" <gi*******@mariani.wswrote in message

....

What do you think?

That was posix code. Does Posix have WAIT_ABADONED?

The windows code does not use Win32 (at least the code I wrote).

[Chris Thomasson]

"Gianni Mariani" <gi*******@mariani.wswrote in message
news:48********@news.mel.dft.com.au...

Chris Thomasson wrote:

>"Gianni Mariani" <gi*******@mariani.wswrote in message

...

>What do you think?

That was posix code. Does Posix have WAIT_ABADONED?

Some POSIX implementations have extensions which support so-called robust
mutexs. In such environments, EOWNERDEAD is analogous to WAIT_ABANDONED. I
believe that they will become standard in the future.

The windows code does not use Win32 (at least the code I wrote).

You Windows abstraction:

http://austria.svn.sourceforge.net/v...ria/win32/code

does not use Win32?
BTW, I took a quick look at your code-base. AFAICT, its very clean and easy
to read. Good job!

:^D

[Chris Thomasson]

"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:20**********************************@d1g2000h sg.googlegroups.com...

On Jun 1, 10:26 am, "Chris Thomasson" <[e-mail]:

"Chris Forone" <[e-mail] in message

news:g1**********@newsreader2.utanet.at...
[...\]Thanks for the example. In my case its an "active object" as a
timer. The

sync is for a "suspend point" (you said), to Resume/Suspend in a well
defined section. The approach with thread creation at first Start() i
can
use eventually, i create the thread in ctor w/ CREATE_SUSPENDED, saw
in
the web, create thread in ctor is evil...

[...]

Creating threads in a ctor is generally considered evil indeed. However,
starting threads(s) in ctors which act on
___fully___constructed___object(s)___ is NOT! Case in point:

http://groups.google.com/group/comp....c14991f9e88482

Any thoughts?

As for one remark, you and your enthusiastic friend tried really hard
but finally you could not prove or demonstrate that starting a thread
as the last step in the constructor could result in any problem
provided one is disciplined enough.

AFAICT, the OP in that thread was a __newbie__ thinking about starting a
thread in the ctor of a threading base class. I was tring to explain how a
nasty race-condition could arise in that scenario. Alls you said was that
starting threads in ctors is no big deal if you know what your doing. Well,
the OP was on the verge of making a mistake, and I felt the need to put up a
big warning sign. So be it.

In fact I have deduced it from the
text of the standard that nothing forbids it.

Second, you yourself solved your own problem or doubt by simply
providing a wrapper template (see your own link).

The only point I was trying to make was that you should only start threads
which act on fully constructed objects. Therefore, starting a thread from an
object ctos which is intended to operator on itself is an error. The
active<Ttemplate gets around that limitation by acting as a proxy. It
works very well.

Third, the concept of _active object_ is a well known concept in
computer science except for in the circles of C++ hackers.

That's not true in all cases.

[Chris Thomasson]

"Chris Thomasson" <cr*****@comcast.netwrote in message
news:3b******************************@comcast.com. ..

"Gianni Mariani" <gi*******@mariani.wswrote in message
news:48********@news.mel.dft.com.au...

>Chris Thomasson wrote:

>>"Gianni Mariani" <gi*******@mariani.wswrote in message

...

>>What do you think?

That was posix code. Does Posix have WAIT_ABADONED?

Some POSIX implementations have extensions which support so-called robust
mutexs. In such environments, EOWNERDEAD is analogous to WAIT_ABANDONED. I
believe that they will become standard in the future.

>The windows code does not use Win32 (at least the code I wrote).

You Windows abstraction:

http://austria.svn.sourceforge.net/v...ria/win32/code

does not use Win32?

I must be completely misunderstanding you because I see Windows API calls
all over the place in the code residing in the `win32/code' directory.

[Chris Thomasson]

"Chris Thomasson" <cr*****@comcast.netwrote in message
news:p8******************************@comcast.com. ..

>
"Chris Forone" <4o**@gmx.atwrote in message
news:g1**********@newsreader2.utanet.at...
[...\]

>Thanks for the example. In my case its an "active object" as a timer. The
sync is for a "suspend point" (you said), to Resume/Suspend in a well
defined section. The approach with thread creation at first Start() i can
use eventually, i create the thread in ctor w/ CREATE_SUSPENDED, saw in
the web, create thread in ctor is evil...

[...]

Creating threads in a ctor is generally considered evil indeed.

[...]

One reason why you need to be VERY careful:

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!

[Jerry Coffin]

In article <l5******************************@comcast.com>,
cr*****@comcast.net says...

[ ... ]

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

You can _create_ the thread, but you must ensure against it _running_
until the ctor has finished executing. I can't say with certainty that
all environments support creating threads in a suspended state, but some
(e.g. Win32) certainly do.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Szabolcs Ferenczi]

On Jun 2, 6:33*am, "Chris Thomasson" <[e-mail]:

"Szabolcs Ferenczi" <[e-mail] in message
[...]
All[s] you said was that
starting threads in ctors is no big deal if you know what your doing.

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

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

You have given a false warning. That is it.

In fact I have deduced it from the
text of the standard that nothing forbids it.
Second, you yourself solved your own problem or doubt by simply
providing a wrapper template (see your own link).

The only point I was trying to make was that you should only start threads
which act on fully constructed objects.

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

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

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

Therefore, starting a thread from an
object ctos which is intended to operator on itself is an error.

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

The
active<Ttemplate gets around that limitation by acting as a proxy. It
works very well.

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

Third, the concept of _active object_ is a well known concept in
computer science except for in the circles of C++ hackers.

That's not true in all cases.

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

Best Regards,
Szabolcs

[Ian Collins]

Szabolcs Ferenczi wrote:

On Jun 2, 6:33 am, "Chris Thomasson" <[e-mail]:

>The only point I was trying to make was that you should only start threads
which act on fully constructed objects.

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

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

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

--
Ian Collins.

[Szabolcs Ferenczi]

On Jun 2, 9:15*pm, Ian Collins <[e-mail]:

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

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

Best Regards,
Szabolcs

[peter koch]

On 2 Jun., 20:27, Szabolcs Ferenczi <[e-mail]>
wrote:

On Jun 2, 6:33 am, "Chris Thomasson" <[e-mail]:

"Szabolcs Ferenczi" <[e-mail] in message
[...]
All[s] you said was that
starting threads in ctors is no big deal if you know what your doing.

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

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

You have given a false warning. That is it.

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

>

In fact I have deduced it from the
text of the standard that nothing forbids it.
Second, you yourself solved your own problem or doubt by simply
providing a wrapper template (see your own link).

The only point I was trying to make was that you should only start threads
which act on fully constructed objects.

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

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

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

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

>

Therefore, starting a thread from an
object ctos which is intended to operator on itself is an error.

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

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

>

The
active<Ttemplate gets around that limitation by acting as a proxy. It
works very well.

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

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

>

Third, the concept of _active object_ is a well known concept in
computer science except for in the circles of C++ hackers.

That's not true in all cases.

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

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

/Peter

[Szabolcs Ferenczi]

On Jun 2, 11:05*pm, peter koch <[e-mail]:

On 2 Jun., 20:27, Szabolcs Ferenczi <[e-mail]>
wrote:

On Jun 2, 6:33 am, "Chris Thomasson" <[e-mail]:

"Szabolcs Ferenczi" <[e-mail] in message
[...]
All[s] you said was that
starting threads in ctors is no big deal if you know what your doing.

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

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

You have given a false warning. That is it.

No. That warning was not false.

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

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

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

[...]

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

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

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

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

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

The
active<Ttemplate gets around that limitation by acting as a proxy. It
works very well.

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

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

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

This certainly is the case
in my thread templateclass).

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

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

Best Regards,
Szabolcs

[Chris Thomasson]

"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:1b**********************************@f63g2000 hsf.googlegroups.com...

On Jun 2, 6:33 am, "Chris Thomasson" <[e-mail]:

"Szabolcs Ferenczi" <[e-mail] in message
[...]
All[s] you said was that
starting threads in ctors is no big deal if you know what your doing.

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

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

You have given a false warning. That is it.

Its not a false warning. If the OP in the following discussion:

http://groups.google.com/group/comp....cae1851bb5f215

actually implemented and used his original idea of starting the thread in
the ctor of the base threading class which in turn calls a pure virtual
function _before_ said ctor completes, well, the result would have
been --BOOM!--; this is due to a race-condition. Why can't you see that? I
now ask you to prove to me that the OP original idea of starting a pthread
in the constructor of the threading base class is okay. I gave an example
program which clearly shows why its NOT a good idea:

http://groups.google.com/group/comp....2b8acb1d6a12fb
Where is your counter? Keep in mind that the OP wanted to use a thread-base
class. Your initial advise was that its okay to spawn threads in ctors if
you know what your doing. How does that help the OP? He was heading down the
wrong path, and you failed to mention any of the caveats. When I brought
them to the OP's attention, you basically said something like 'ahh, don't
worry. Chris does not know what he is talking about. The caveats he mentions
do not exist' Why did you do that?

In fact I have deduced it from the
text of the standard that nothing forbids it.
Second, you yourself solved your own problem or doubt by simply
providing a wrapper template (see your own link).

The only point I was trying to make was that you should only start
threads
which act on fully constructed objects.

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

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

There is no concept of not `fully constructed object' with respect to
calling its own methods.

I am talking about calling a pure virtual function from a ctor via a proxy
agent (aka, thread entry function). This does NOT work.

It is allowed to call any method during
construction. On the other hand, the object must be fully constructed
if you are trying to use it from its external environment. This is
what you wrongfully interpret in this case.

The object MUST be fully constructed before the created thread operates on
it. The active<Thelper object ensures this.

Therefore, starting a thread from an
object ctos which is intended to operator on itself is an error.

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

The language does not know anything about threads yet. Anyway, like I said,
If the threading is implemented as a base class with an abstract virtual
function representing the threads "entry" point, then you simply cannot
create _and_ run 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!

The
active<Ttemplate gets around that limitation by acting as a proxy. It
works very well.

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

Your misunderstanding the active<Tobject a little bit.
__________________________________________________ _______________
template<typename T>
struct active {
class guard {
T& m_object;

public:
guard(T& object) : m_object(object) {
m_object.start();
}

~guard() {
m_object.join();
}
};

T m_object;

active() {
m_object.start();
}

~active() {
m_object.join();
}

};
__________________________________________________ _______________


See, it can start the thread in its ctor because said thread does NOT
operate on the active<Tobject as a whole. It only ever operates on a
single fully constructed member of it (e.g., `active<T>::m_object' -or-
`active<T>::guard::m_object'). Therefore, my initial rule that says threads
cannot operate on objects which are not fully constructed is NOT broken.
This is because the `active<T>::m_object' is 100% fully constructed inside
the `active<T>::active' constructor.

Third, the concept of _active object_ is a well known concept in
computer science except for in the circles of C++ hackers.

That's not true in all cases.

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

Sure.

[Chris Thomasson]

"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP***********************@news.sunsite.dk...

In article <l5******************************@comcast.com>,
cr*****@comcast.net says...

[ ... ]

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

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

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

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

int main() {
{
active<objectmy_object;
}
return 0;
}

______________________________________________
Simple.

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

Indeed.

[Chris Forone]

Chris Thomasson schrieb:

"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP***********************@news.sunsite.dk...

>In article <l5******************************@comcast.com>,
cr*****@comcast.net says...

[ ... ]

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

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

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

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

int main() {
{
active<objectmy_object;
}
return 0;
}

______________________________________________
Simple.

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

Indeed.

Why not locking the ctor?

best regards, chris

[Ian Collins]

Szabolcs Ferenczi wrote:

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

Pot, kettle.

--
Ian Collins.

[Ian Collins]

Chris Forone wrote:

Chris Thomasson schrieb:

>"Jerry Coffin" <jc*****@taeus.comwrote:

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

Indeed.

Why not locking the ctor?

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

--
Ian Collins.

[James Kanze]

On Jun 2, 8:27 pm, Szabolcs Ferenczi <[e-mail]>
wrote:

On Jun 2, 6:33 am, "Chris Thomasson" <[e-mail]:

"Szabolcs Ferenczi" <[e-mail] in message
[...]
All[s] you said was that starting threads in ctors is no big
deal if you know what your doing.

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

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

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

You have given a false warning. That is it.

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

--
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, [phone]

[Chris Thomasson]

"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:c9**********************************@y21g2000 hsf.googlegroups.com...
On Jun 2, 11:05 pm, peter koch <[e-mail]:
[...]

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

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

Check out the following tweak I made to my `active<T>':

http://groups.google.com/group/comp....b35fbf7026cb3a

This should make it more flexible indeed.

[...]

[peter koch]

On 2 Jun., 23:48, Szabolcs Ferenczi <[e-mail]>
wrote:

On Jun 2, 11:05*pm, peter koch <[e-mail]:

On 2 Jun., 20:27, Szabolcs Ferenczi <[e-mail]>
wrote:

On Jun 2, 6:33 am, "Chris Thomasson" <[e-mail]:

"Szabolcs Ferenczi" <[e-mail] in message
[...]
All[s] you said was that
starting threads in ctors is no big deal if you know what your doing..

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

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

You have given a false warning. That is it.

No. That warning was not false.

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

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

>

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

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

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

>

[...]

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

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

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

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

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

The
active<Ttemplate gets around that limitation by acting as a proxy.It
works very well.

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

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

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

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

>

This certainly is the case
in my thread templateclass).

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

Again, I never did oppose that.

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

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

/Peter

[Szabolcs Ferenczi]

On Jun 3, 6:59*pm, peter koch <[e-mail]:

On 2 Jun., 23:48, Szabolcs Ferenczi <[e-mail]>
wrote:
[...]

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

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

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

If you do not remember, I can fresh up your memory. Here you go:
http://groups.google.com/group/comp....57c21f016ad3e2

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

Q.E.D.

I hope I was of help.

Best Regards,
Szabolcs

[Chris Thomasson]

"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:1a**********************************@d45g2000 hsc.googlegroups.com...
On Jun 3, 6:59 pm, peter koch <[e-mail]:

On 2 Jun., 23:48, Szabolcs Ferenczi <[e-mail]>
wrote:
[...]

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

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

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

If you do not remember, I can fresh up your memory. Here you go:
http://groups.google.com/group/comp....57c21f016ad3e2

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

IMHO, C++ needs to be able to provide the means to create low-level
non-blocking synchronization patterns. Therefore, it needs to offer raw
fine-grain atomic operations and memory barriers and give the programmer
fine-grain control over exactly where they go in a particular algorithm. I
don't quite see hoe you can do that with high-level constructs. Keep in mind
that C++ should still be able to interface with assembly language with PODS.
IMVHO, the more high-level items you add, the more you take away from the
low-level spirit of a systems language such as C++...

[...]

[peter koch]

On 3 Jun., 21:13, Szabolcs Ferenczi <[e-mail]>
wrote:

On Jun 3, 6:59*pm, peter koch <[e-mail]:

On 2 Jun., 23:48, Szabolcs Ferenczi <[e-mail]>
wrote:
[...]

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

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

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

If you do not remember, I can fresh up your memory. Here you go:http://groups.google.com/group/comp....57c21f016ad3e2

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

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

My conclusion: you are a fool!

/Peter

[Szabolcs Ferenczi]

On Jun 3, 11:20*pm, peter koch <[e-mail]:

On 3 Jun., 21:13, Szabolcs Ferenczi <[e-mail]>
wrote:

On Jun 3, 6:59*pm, peter koch <[e-mail]:

On 2 Jun., 23:48, Szabolcs Ferenczi <[e-mail]>
wrote:
[...]
Dealing with threads is not
straightforward, and you have to be at least a little bit careful.

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

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

If you do not remember, I can fresh up your memory. Here you go:http://groups.google.com/group/comp....57c21f016ad3e2

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

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

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

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

Best Regards,
Szabolcs

[Jerry Coffin]

In article <It******************************@comcast.com>,
cr*****@comcast.net says...

[ ... ]

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

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

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

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

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

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Chris Thomasson]

"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP************************@news.sunsite.dk...

In article <It******************************@comcast.com>,
cr*****@comcast.net says...

[ ... ]

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

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

;^D

>

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

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

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

Indeed.