Q: use CreateThread() and TerminateThread() and message procedure

538 views
Skip to first unread message

JCR

unread,
Mar 26, 2002, 6:00:48 AM3/26/02
to
Hi all,

I use CreateThread() and TerminateThread() in a simple program.
Run/Stop the Thread works well, and the calling app. receives
feedback 'acknowledge' messages as well, so I know that the HWND
catched from the calling proc. is the right one.

Now, the problem here is that the app. doesn't receive MSG_FINISHED,
which is sent by the threaded procedure (fThreadProc) when it stops.
By the way, is it correct to do a call to TerminateThread()
from the inside of the threaded procedure itself ?

Below is a sample code that compiles to a DLL, loaded at startup
by the test app. that calls 'fRunThread()' when I click a button.
Why does my app receive MSG_STARTED and MSG_STOPPED
messages, but never receives the MSG_FINISHED message ?

TIA,
Jean-Christophe

// CODE START /////////////////////////////////////////////////////

//messages

#define MSG_ACK 101 //positive acknowledge
#define MSG_NACK 102 //negative acknowledge
#define MSG_STARTED 103 //thread started
#define MSG_STOPPED 104 //thread stopped (break)
#define MSG_FINISHED 105 //thread stopped (job complete)

// Global

HINSTANCE hDllInst = 0; //DLL instance
HWND hCallWnd = 0; //caller hwnd handler
HANDLE hThread = 0; //thread handle


//--------------------------------------------------------------
// Thread proc
//--------------------------------------------------------------
DWORD WINAPI fThreadProc( LPVOID lpParameter )
{
DWORD dw=500;

//dummy loop
while( --dw )
{ Sleep(10);
}

//auto stop
if(hThread)
TerminateThread(hThread,0);

if(hCallWnd)
SendMessage( hCallWnd, WM_COMMAND, MSG_FINISHED, 0 );

return 0;
}


//--------------------------------------------------------------
// Run thread
//--------------------------------------------------------------
WORD fRunThread()
{
LPTHREAD_START_ROUTINE lpThreadProc =
(LPTHREAD_START_ROUTINE)(fEquilThreadProc);
DWORD dwStack = 16 * 1024; //stack
LPVOID lpParam = NULL; //params
DWORD dwFlags = 0; //CREATE_SUSPENDED;//run thru DWORD
ResumeThread( HANDLE hThread );
DWORD dwThreadId = 0; //ID
LPDWORD lpThreadId = &dwThreadId; //*ID

//check
if(hThread)
return MSG_NACK;//thread already used

//create
hThread = CreateThread( NULL, dwStack, lpEquilThreadProc, lpParam,
dwFlags, lpThreadId );

if(!hThread)
return MSG_NACK;//oops

return MSG_STARTED;//ok
}


//--------------------------------------------------------------
// Stop calc thread
//--------------------------------------------------------------
WORD fStopEquilThread()
{
BOOL b = FALSE;

//check

if(!hThread)
return MSG_NACK;//no thread to stop

//stop

b = TerminateThread(hThread,1);

//chack
if(b==FALSE)
return MSG_NACK;//failed

hThread = 0;//reset

return MSG_STOPPED;//ok
}
// CODE ENDS //////////////////////////////////////////////////////////

Arnold Hendriks

unread,
Mar 26, 2002, 6:19:33 AM3/26/02
to
In comp.programming.threads JCR <Jean-Christo...@genebio.com> wrote:
> I use CreateThread() and TerminateThread() in a simple program.
Calls like TerminateThread are extremely disruptive and dangerous because
you could be killing a thread holding critical resources. Proper recovery
is almost impossible after a termination.

> Now, the problem here is that the app. doesn't receive MSG_FINISHED,
> which is sent by the threaded procedure (fThreadProc) when it stops.
> By the way, is it correct to do a call to TerminateThread()
> from the inside of the threaded procedure itself ?

How can your thread send a message when it has just committed suicide?

> DWORD WINAPI fThreadProc( LPVOID lpParameter )

...
> LPTHREAD_START_ROUTINE lpThreadProc =
> (LPTHREAD_START_ROUTINE)(fEquilThreadProc);
What is this 'fEquilThreadProc'? For my answer I just assumed you meant
fThreadProc. BTW: a cast like this shouldn't be necessary. Avoid a cast
whenever you can, because you might be hiding a problem with eg. calling
conventions and calling syntax with this.

--
Arnold Hendriks <a.hen...@b-lex.com>
B-Lex Information Technologies, http://www.b-lex.com/

Alexander Terekhov

unread,
Mar 26, 2002, 7:15:29 AM3/26/02
to
JCR wrote:
>
> Hi all,
>
> I use CreateThread() and TerminateThread() in a simple program.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q254956

"Owned mutexes are considered abandoned but this can be detected. "

but associated shared data will be totally broken nevertheless.

"Other synchronization objects that the thread acquired are now
left unreleased. For example, critical sections that were entered
by the terminated thread are not released.

If the target thread was executing certain kernel32 calls when
it is terminated, the kernel32 state for the thread's process
could be inconsistent.

If the target thread is manipulating the global state of a
shared DLL, the state of the DLL could be inconsistent,
affecting other users of the DLL.

The stack memory that is used by the thread is lost and not
recovered until the process ends. A long-running process must
not do this because eventually all its address space will be used.
A few of these terminations a day over the course of a few months
will cause this problem. "

Yeah, and for "a short-running" process that's just OK! Idiotic.

"Because of all these issues with state leakage and corruption,
it is not a good idea to use the TerminateThread function. "

Hey MS-folks, but it was really "a good idea" to release such
brain-damaged thing! Really!! Thanks!!!

"The best approach to terminate threads gracefully is ...."

THIS:

http://sources.redhat.com/pthreads-win32

regards,
alexander.

Maxim S. Shatskih

unread,
Mar 26, 2002, 8:12:13 AM3/26/02
to
> By the way, is it correct to do a call to TerminateThread()
> from the inside of the threaded procedure itself ?

TerminateThread is a very bad function, and people from MS have un-recommend using it several times.
For instance, it causes the thread's user stack to go to leak.

Max

Maxim S. Shatskih

unread,
Mar 26, 2002, 8:42:15 AM3/26/02
to
> "The best approach to terminate threads gracefully is ...."
>
> THIS:
>
> http://sources.redhat.com/pthreads-win32

Do they use native NT or Win32 threads as a lower layer?
If not - then this is yet another "user mode threads" piece of crap.

Max

Arnold Hendriks

unread,
Mar 26, 2002, 9:32:22 AM3/26/02
to
In comp.programming.threads Maxim S. Shatskih <ma...@storagecraft.com> wrote:
>> "The best approach to terminate threads gracefully is ...."
>> THIS:
>> http://sources.redhat.com/pthreads-win32
> Do they use native NT or Win32 threads as a lower layer?
Native threads.

Tim Robinson

unread,
Mar 26, 2002, 9:43:11 AM3/26/02
to
"Arnold Hendriks" <a.hen...@b-lex.com> wrote in message
news:a7q0pm$qq2$1...@news.btcnet.nl...

| >> http://sources.redhat.com/pthreads-win32
| > Do they use native NT or Win32 threads as a lower layer?
| Native threads.

Do they use the native NT thread API or the Win32 thread API?

--
Tim Robinson
http://www.themoebius.org.uk/

Alexander Terekhov

unread,
Mar 26, 2002, 9:36:17 AM3/26/02
to

Why don't you just click on link and find it out yourself?

As for "piece of crap"... it is really hard to beat MS
stuff (APIs) in this respect (and THREADING especially).

regards,
alexander.

Pete Lee

unread,
Mar 26, 2002, 1:37:03 PM3/26/02
to
Alexander Terekhov <tere...@web.de> wrote in news:3CA06661.D8EBCF54
@web.de:

> Hey MS-folks, but it was really "a good idea" to release such
> brain-damaged thing! Really!! Thanks!!!
>
> "The best approach to terminate threads gracefully is ...."
>
> THIS:
>
> http://sources.redhat.com/pthreads-win32
>

I fail to see how pthreads-win32 prevents you from calling TerminateThread
on the underlying thread handle.

You may think the api is better. I disagree, but that is a seperate
discussion. Regardless of whether you use the win32 api's, the c-runtime
lib, or pthreads-win32, you will still have problems if you call
TerminateThread on a thread handle regardless of what you used to create
it.

So what exactly was your point ?

Maxim S. Shatskih

unread,
Mar 26, 2002, 3:25:54 PM3/26/02
to
> Do they use the native NT thread API or the Win32 thread API?

They are very, very similar, IIRC the main difference is that native NT thread API does not support user stack allocation, it must
be allocated separately.
kernel32!CreateThread calls BaseCreateStack, and only then ntdll!NtCreateThread.

Max

Maxim S. Shatskih

unread,
Mar 26, 2002, 3:27:36 PM3/26/02
to
> As for "piece of crap"... it is really hard to beat MS
> stuff (APIs) in this respect (and THREADING especially).

I personally consider Win32 threading and sync objects API as very good, except this ugly TerminateThread, which is known to be a
PITA to all serious Win32 developer.
This function seems to exist for things like debuggers, and not for production apps.

Max

Davlet Panech

unread,
Mar 26, 2002, 5:41:35 PM3/26/02
to
Pete Lee wrote:
>
> Alexander Terekhov <tere...@web.de> wrote in news:3CA06661.D8EBCF54
> @web.de:
> > Hey MS-folks, but it was really "a good idea" to release such
> > brain-damaged thing! Really!! Thanks!!!
> >
> > "The best approach to terminate threads gracefully is ...."
> >
> > THIS:
> >
> > http://sources.redhat.com/pthreads-win32
> >
>
> I fail to see how pthreads-win32 prevents you from calling TerminateThread
> on the underlying thread handle.
>
> You may think the api is better. I disagree, but that is a seperate
> discussion.

You can't be serious!

> Regardless of whether you use the win32 api's, the c-runtime
> lib, or pthreads-win32, you will still have problems if you call
> TerminateThread on a thread handle regardless of what you used to create
> it.
>
> So what exactly was your point ?

The point is, PTHREADS implement thread cancellation, Win32 doesn't,
which makes doing many things a major pain in the butt. With regards
to TerminateThread(), look at it this way: we have a function that
basically damages your process' execution environment, and therefore
should not be used under any circumstances -- why is it then supported?
It causes nothing but grief to those careless enough to use it! Is
that the API *you* prefer?

D.P.

Pete Lee

unread,
Mar 27, 2002, 1:23:12 AM3/27/02
to
>> You may think the api is better. I disagree, but that is a seperate
>> discussion.
> You can't be serious!

There are plenty of wrapper/helper thread classes out there that hide
some/all of the details of thread management, but no matter which one you
use, in all cases bad things will happen if you call TerminateThread
(pthreads included).

> The point is, PTHREADS implement thread cancellation, Win32 doesn't,
> which makes doing many things a major pain in the butt.

Ok, so it implements thread cancellation... so? 99.3235% of the 53238
thread wrappers (those are accurate numbers btw) on the net implement
cancellation. It's trivial to do.

> With regards
> to TerminateThread(), look at it this way: we have a function that
> basically damages your process' execution environment, and therefore
> should not be used under any circumstances -- why is it then
> supported?

Why speculate as to why it's supported? It really doesnt matter why, the
fact is it *IS* supported and so long as the function exists, newbs are
going to get in trouble if they use it regardless of whether they are using
a wrapper/helper class (like pthreads, CWinThread, threads++, ...) or pure
win32. So instead of screaming "USE PTHREADS" you should be saying "DONT
USE TERMINATETHREAD".

JCR

unread,
Mar 27, 2002, 4:45:59 AM3/27/02
to
Arnold Hendriks <a.hen...@b-lex.com> wrote in message news:<a7plg5$j70$1...@news.btcnet.nl>

> In comp.programming.threads JCR <Jean-Christo...@genebio.com> wrote:
> > I use CreateThread() and TerminateThread() in a simple program.
> > Now, the problem here is that the app. doesn't receive MSG_FINISHED,
> > which is sent by the threaded procedure (fThreadProc) when it stops.
> How can your thread send a message when it has just committed suicide?
Argh! Was so obvious that I didn't see, thanks to 'Arnold.H'.

Ok Guys, everything works well after suppression of TerminateThread!
The threaded procedure sends a message before ending, simple n'easy.
A case of runtime suicide (sigh) forwarded to alt.suicide.recovery

BTW, you were too hard with MS, which will proudly provide a definitive
replacement for TerminateThread(), named TerminateEverything().
So then you'll know that your thread IS done. Every thread, in fact.
JCR

Davlet Panech

unread,
Mar 27, 2002, 9:40:28 AM3/27/02
to
Pete Lee wrote:
>
> >> You may think the api is better. I disagree, but that is a seperate
> >> discussion.
> > You can't be serious!
>
> There are plenty of wrapper/helper thread classes out there that hide
> some/all of the details of thread management, but no matter which one you
> use, in all cases bad things will happen if you call TerminateThread
> (pthreads included).
>
> > The point is, PTHREADS implement thread cancellation, Win32 doesn't,
> > which makes doing many things a major pain in the butt.
>
> Ok, so it implements thread cancellation... so? 99.3235% of the 53238
> thread wrappers (those are accurate numbers btw) on the net implement
> cancellation. It's trivial to do.

"Trivial"? Hmm... The truth is it is impossible to support thread
cancellation
completely on Windows as some system have no non-blocking equivalents
(such
as CreateFile for openning an existing file on the "remote" filesystem
for
example). Not to mention things like COM, RPC, etc. But I see your point
--
until Windows provides built-in support for cancellation it can't be
correctly
emulated by any wrappers (pthreads included).

>
> > With regards
> > to TerminateThread(), look at it this way: we have a function that
> > basically damages your process' execution environment, and therefore
> > should not be used under any circumstances -- why is it then
> > supported?
>
> Why speculate as to why it's supported? It really doesnt matter why, the
> fact is it *IS* supported and so long as the function exists, newbs are
> going to get in trouble if they use it regardless of whether they are using
> a wrapper/helper class (like pthreads, CWinThread, threads++, ...) or pure
> win32. So instead of screaming "USE PTHREADS" you should be saying "DONT
> USE TERMINATETHREAD".

The question remains: how do you cancel a thread in Windows? Generally
speaking you can't ( even with the pthreads port ).

D.P.

Maxim S. Shatskih

unread,
Mar 27, 2002, 9:17:14 AM3/27/02
to
> The point is, PTHREADS implement thread cancellation, Win32 doesn't,
> which makes doing many things a major pain in the butt.

What is thread cancellation?
Is it the ability of sending a SIGINT-like signal to a thread, which will interrupt it, force it to execute some rundown code and
quit?

If yes - this is an extremely dangerous thing, at least as dangerous as TerminateThread.
For instance - let's imagine your thread have just allocated some memory or constructred some complex C++ object. Then this signal
arrives. Without lots of extra annoying bug-prone code, there are huge chances you will have a very complex memory and resource
leak.

The only bug-free way is that the thread can only quit itself and cannot be terminated.
Attempts to terminate the thread from outside must only be treated as "advice" by the thread, which can be delayed till some "good"
time or ignored.

NT kernel uses this for sure internally. The thread cannot be terminated while in kernel.
Terminate attempt will be scheduled for it, but the actual exit sequence will occur on next return from kernel to user. Kernel-only
threads in NT cannot be terminated at all - they can only quit themselves.

Usually, some "manual" solutions are used in Win32 to send this "advice" to the thread. This can be some shutdown event object, or
QueueUserApc or volatile global variable.

If you're not satisfied with it - write a C++ class for a thread which will encapsulate the shutdown event (or the shutdown flag) in
it.

> With regards
> to TerminateThread(), look at it this way: we have a function that
> basically damages your process' execution environment

Surely, this is a bad API. Never use it.

Max

Jerry Coffin

unread,
Mar 27, 2002, 10:15:20 AM3/27/02
to
In article <3CA1D9DC...@Tellabs.com>, Davlet...@Tellabs.com
says...

[ ... ]

> "Trivial"? Hmm... The truth is it is impossible to support thread
> cancellation completely on Windows as some system have no non-
> blocking equivalents (such as CreateFile for openning an existing
> file on the "remote" filesystem for example). Not to mention
> things like COM, RPC, etc. But I see your point -- until Windows
> provides built-in support for cancellation it can't be correctly
> emulated by any wrappers (pthreads included).

I think it should be pointed out that your use of "correct" above is
a bit misleading: there are some fairly clear differences between
POSIX threads and Win32 threads, and it's true that if you try to
support one on the other, it's impossible to do that entirely
correctly. That runs in both directions though: just as Win32
doesn't support cancellation "correctly", POSIX doesn't support
suspended threads (for only one example) "correctly".

In the end, while Win32 threads have some pitfalls to look out for,
after you know what you're doing, I believe it's a lot easier to make
good use of them than it is to make equally good use of pthreads.

From what I've seen, a _reasonably_ usable implementation of pthreads
on top of Win32 threads is _fairly_ easy to manage, while the reverse
seems to border on impossible.

--
Later,
Jerry.

The Universe is a figment of its own imagination.

Alexander Terekhov

unread,
Mar 27, 2002, 10:21:25 AM3/27/02
to

Pete Lee wrote:
[...]

> So instead of screaming "USE PTHREADS"
> you should be saying "DONT USE TERMINATETHREAD".

Okay, here we go:

DONT USE SUSPEND/RESUME
DONT USE EVENTS
DONT USE SEMAPHORES
DONT USE WAITFORMULTIPLESTUFF
DONT USE INTERLOCKEDSTUFF
DONT USE NON-SYNC-ACCESS (follow portable memory sync. rules)

Uhmm, other than simple mutexes and "I/O Completion Ports"
thread pooling, is there any MS-threading stuff I forgot
to "DONT USE IT"? The bottom line/general advice is:

USE PTHREADS... and (full 1,2,3,4,5 list):

http://groups.google.com/groups?as_umsgid=c29b5e33.0201240004.57d109f4%40posting.google.com

regards,
alexander.

Tim Robinson

unread,
Mar 27, 2002, 10:36:46 AM3/27/02
to
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3CA1E375...@web.de...

| > So instead of screaming "USE PTHREADS"
| > you should be saying "DONT USE TERMINATETHREAD".
|
| Okay, here we go:
|
| DONT USE SUSPEND/RESUME
| DONT USE EVENTS
| DONT USE SEMAPHORES
| DONT USE WAITFORMULTIPLESTUFF
| DONT USE INTERLOCKEDSTUFF
| DONT USE NON-SYNC-ACCESS (follow portable memory sync. rules)

Why not?!

Maxim S. Shatskih

unread,
Mar 27, 2002, 10:52:17 AM3/27/02
to
> The question remains: how do you cancel a thread in Windows? Generally

What is the need in it at all? A dangerous thing at least.
BTW, COM and RPC are extremely useful things, much more useful then thread cancellation.

Max

Maxim S. Shatskih

unread,
Mar 27, 2002, 11:10:14 AM3/27/02
to
> Okay, here we go:
>
> DONT USE SUSPEND/RESUME

Agree. This is deadlock prone.

> DONT USE EVENTS

Why not? I see no reasons in not using events.
UNIX-style "condvars" are really atrocious compared to Win32/NT events.
As about NT kernel events - they are really great, since they can be created anywhere - even on stack - without bothering to
allocate them in some special way.
Linux kernel also has the "waitqueue" object which is nearly the same as NT's KEVENT.
Good ideas are reused in many implementations, you see.

> DONT USE SEMAPHORES

Why not? A convinient object sometimes.

> DONT USE WAITFORMULTIPLESTUFF

Again why not?

> DONT USE INTERLOCKEDSTUFF

Again why not? Sometimes it is convinient, especially in the kernel.

> thread pooling, is there any MS-threading stuff I forgot
> to "DONT USE IT"? The bottom line/general advice is:

Sorry, I'm free from MSphobic biases, thus I cannot understand your advices.
:-)

Max

Alexander Terekhov

unread,
Mar 27, 2002, 12:42:30 PM3/27/02
to

"Maxim S. Shatskih" wrote:
>
> > Okay, here we go:
> >
> > DONT USE SUSPEND/RESUME
>
> Agree. This is deadlock prone.
>
> > DONT USE EVENTS
>
> Why not?

Because this is race-condition prone, to begin with.

> I see no reasons in not using events.
> UNIX-style "condvars" are really atrocious compared to Win32/NT events.

You better learn how to use them first, before making such statements.
See No "1." in the "1,2,3,4,5" list.

> As about NT kernel events - they are really great,

I don't really care much about "kernel" internal stuff, however:

> since they can be created anywhere - even on stack - without bothering to
> allocate them in some special way.
> Linux kernel also has the "waitqueue" object which is nearly the same as NT's KEVENT.

http://users.footprints.net/~kaz/lmc.html

"Home of LMC

LMC stands for Linux Mutexes and Conditions. It is a small C
header file and source file which implements these mutual
exclusion and synchronization primitives to be used in
Linux kernel programming. It comes with a brief white
paper that explains why these things are useful, and how
they are used. ..."

> Good ideas are reused in many implementations, you see.
>
> > DONT USE SEMAPHORES
>
> Why not? A convinient object sometimes.

Again, study condvars... you'll see it then.

> > DONT USE WAITFORMULTIPLESTUFF
>
> Again why not?

See above.

> > DONT USE INTERLOCKEDSTUFF
>
> Again why not? Sometimes it is convinient, especially in the kernel.

Memory synchronization, busy-waiting, etc..

> > thread pooling, is there any MS-threading stuff I forgot
> > to "DONT USE IT"? The bottom line/general advice is:
>
> Sorry, I'm free from MSphobic biases, thus I cannot understand your advices.
> :-)

How can I help you ("MSphobic biases" aside)?

regards,
alexander.

Alexander Terekhov

unread,
Mar 27, 2002, 2:56:40 PM3/27/02
to

"Maxim S. Shatskih" wrote:
>
> > The point is, PTHREADS implement thread cancellation, Win32 doesn't,
> > which makes doing many things a major pain in the butt.
>
> What is thread cancellation?
[...async.cancel is dangerous/bad...]

In addition to "1." from the 1..5 list (I mean
http://www.awl.com/cseng/titles/0-201-63392-2/ ),
you might want to take a look at this discussion:

http://groups.google.com/groups?threadm=3C7BD6B3.1EAE29D0%40web.de

regards,
alexander.

Jerry Coffin

unread,
Mar 27, 2002, 4:29:47 PM3/27/02
to
In article <3CA20486...@web.de>, tere...@web.de says...

[ ... ]

> > > DONT USE EVENTS
> >
> > Why not?
>
> Because this is race-condition prone, to begin with.

IOW, _you've_ never learned to use them properly, so you assume
nobody else has either.

Events aren't particularly prone to race conditions -- in fact, as
long as you have a reasonable clue of what you're doing, they work
quite nicely.

Pete Lee

unread,
Mar 27, 2002, 4:42:08 PM3/27/02
to
> DONT USE SUSPEND/RESUME
> DONT USE EVENTS
> DONT USE SEMAPHORES
> DONT USE WAITFORMULTIPLESTUFF
> DONT USE INTERLOCKEDSTUFF
> DONT USE NON-SYNC-ACCESS (follow portable memory sync. rules)
>
> Uhmm, other than simple mutexes and "I/O Completion Ports"
> thread pooling, is there any MS-threading stuff I forgot
> to "DONT USE IT"? The bottom line/general advice is:
>
> USE PTHREADS... and (full 1,2,3,4,5 list):

You do realize that pthreads uses those things you say "DONT USE" ? It
uses SuspendThread, ResumeThread, CreateEvent, CreateSemaphore,
WaitForMultipleObjects, WaitForSingleObject, InterlockedIncrement, and
InterlockedDecrement. I still have no idea what your point is other that
you seem to be fanatical about using pthreads.

Alexander Terekhov

unread,
Mar 27, 2002, 5:16:18 PM3/27/02
to

Jerry Coffin wrote:
>
> In article <3CA20486...@web.de>, tere...@web.de says...
>
> [ ... ]
>
> > > > DONT USE EVENTS
> > >
> > > Why not?
> >
> > Because this is race-condition prone, to begin with.
>
> IOW, _you've_ never learned to use them properly, so you assume
> nobody else has either.

No, I do NOT "assume nobody else has either". However, I do
assume that anyone else who really did his homework 100% and
really "learned to use them properly" should have definitely
come to the conclusion "DONT USE EVENTS"... on the 2nd minute
of his subsequent *condvar study*.

> Events aren't particularly prone to race conditions -- in fact, as
> long as you have a reasonable clue of what you're doing, they work
> quite nicely.

How about MSDN authors/reviewers/support folks? Do they
"have a reasonable clue of what you're doing"? No, they
DON'T:

http://groups.google.com/groups?as_umsgid=c29b5e33.0201240132.3d78369f%40posting.google.com

And, I am sorry, but given your rather silly
response I think that you DON'T have it too,
Jerry.

regards,
alexander.

Alexander Terekhov

unread,
Mar 27, 2002, 5:38:10 PM3/27/02
to

Pete Lee wrote:
>
> > DONT USE SUSPEND/RESUME
> > DONT USE EVENTS
> > DONT USE SEMAPHORES
> > DONT USE WAITFORMULTIPLESTUFF
> > DONT USE INTERLOCKEDSTUFF
> > DONT USE NON-SYNC-ACCESS (follow portable memory sync. rules)
> >
> > Uhmm, other than simple mutexes and "I/O Completion Ports"
> > thread pooling, is there any MS-threading stuff I forgot
> > to "DONT USE IT"? The bottom line/general advice is:
> >
> > USE PTHREADS... and (full 1,2,3,4,5 list):
>
> You do realize that pthreads uses those things you say "DONT USE" ? It
> uses SuspendThread, ResumeThread, CreateEvent, CreateSemaphore,
> WaitForMultipleObjects, WaitForSingleObject, InterlockedIncrement, and
> InterlockedDecrement.

Yes, I do realize it. That's the IMPLEMENTATION/INTERNAL stuff, stupid.

What else should it use on brain-damaged Win32 as a client?

Of course, it would be nice/great to have MS-made
fully compliant POSIX/SUS (95/98/01) *subsystem*
(threads included):

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwbgen/html/msdn_posix.asp

Hey, and why don't you tell it to your Microsoft account rep?

> I still have no idea what your point is other that
> you seem to be fanatical about using pthreads.

I am fanatical about good/reasonable/simple/well-defined
programming interfaces/models. Win32-threading isn't such
one. Pthreads IS pretty close to such "ideal"! ;-)

regards,
alexander.

Jerry Coffin

unread,
Mar 27, 2002, 5:55:33 PM3/27/02
to
In article <3CA244B2...@web.de>, tere...@web.de says...

[ ... ]

> No, I do NOT "assume nobody else has either". However, I do
> assume that anyone else who really did his homework 100% and
> really "learned to use them properly" should have definitely
> come to the conclusion "DONT USE EVENTS"... on the 2nd minute
> of his subsequent *condvar study*.

Nonsense.



> > Events aren't particularly prone to race conditions -- in fact, as
> > long as you have a reasonable clue of what you're doing, they work
> > quite nicely.
>
> How about MSDN authors/reviewers/support folks? Do they
> "have a reasonable clue of what you're doing"? No, they
> DON'T:
>
> http://groups.google.com/groups?as_umsgid=c29b5e33.0201240132.3d78369f%40posting.google.com
>
> And, I am sorry, but given your rather silly
> response I think that you DON'T have it too,

Let's see here: you try to prove your statement by referring me to
another message you wrote? And you have the nerve to call anybody
else on earth "silly"? You really are a piece of work Alexander!

In that message, you get even worse: you posted something to some
_Redhat_ server, and you're waiting for some "official" reply --
which, of course, isn't going to happen since the chances of anybody
from MS ever even _reading_ it are almost nil.

Dragan Cvetkovic

unread,
Mar 27, 2002, 5:58:21 PM3/27/02
to
Jerry Coffin <jco...@taeus.com> writes:
> >
> > http://groups.google.com/groups?as_umsgid=c29b5e33.0201240132.3d78369f%40posting.google.com
> >
> > And, I am sorry, but given your rather silly
> > response I think that you DON'T have it too,
>
> Let's see here: you try to prove your statement by referring me to
> another message you wrote? And you have the nerve to call anybody
> else on earth "silly"? You really are a piece of work Alexander!
>
> In that message, you get even worse: you posted something to some
> _Redhat_ server, and you're waiting for some "official" reply --
> which, of course, isn't going to happen since the chances of anybody
> from MS ever even _reading_ it are almost nil.
>

Well, in that message he posts a letter that he has sent to
ms...@microsoft.com previously and for which he hasn't received a
response. What's wrong with it?

Bye, Dragan


--
Dragan Cvetkovic,

To be or not to be is true. G. Boole

Alexander Terekhov

unread,
Mar 27, 2002, 6:40:03 PM3/27/02
to

Uhhmm, I would say that below is a good example
demonstrating "deep" analysis skills of an average
Win32 programmer out there (and their ability to
click on links/read/try-to-understand BEFORE
opening their mouth/producing lines of code/etc).

;-)

Oh, Ah, and I have NO comments, Jerry.

regards,
alexander.

Maxim S. Shatskih

unread,
Mar 27, 2002, 4:10:15 PM3/27/02
to
> > > DONT USE EVENTS
> >
> > Why not?
>
> Because this is race-condition prone, to begin with.

Only if one has "twisted hands".
Any serious development even in Win32 (not to say NT kernel) requires good understanding of what is going on in terms of parallelism
and races. It is better to never code any races then to debug them :-)
Without such an understanding, do not go in for MT programming - regardless of whether this is Win32 or pthreads.

> You better learn how to use them first, before making such statements.

Thanks. I have heard of them from one UNIX guy, a terrifying inconvinient thing.
sleep()/wakeup() is another outdated stuff - even modern UNIXen try to not use them - Linux uses waitqueue which is nearly the same
as NT event.
I prefer NT-style events.

> See No "1." in the "1,2,3,4,5" list.

Oh yes, posing yourself as guru and pointing to the self-promoting article is a very good idea.

> > As about NT kernel events - they are really great,
>
> I don't really care much about "kernel" internal stuff, however:

So why you crosspost to NT kernel newsgroup?

> > Linux kernel also has the "waitqueue" object which is nearly the same as NT's KEVENT.
>
> http://users.footprints.net/~kaz/lmc.html
>
> "Home of LMC
>
> LMC stands for Linux Mutexes and Conditions.

A red herring.
I was speaking on _events in Linux kernel_, not on some LMC.

> > > DONT USE WAITFORMULTIPLESTUFF
> >
> > Again why not?
>
> See above.

Sorry, I prefer multiple waits :-) though yes, they are rarely needed.
In fact, Linux uses this semantics _only_ for select()/poll() - without bothering to encapsulate the dispatcher properly. :-)

> > > DONT USE INTERLOCKEDSTUFF
> >
> > Again why not? Sometimes it is convinient, especially in the kernel.
>
> Memory synchronization

Automatic on interlocked operations.

>, busy-waiting

The person must be sane enough to understand whether he wants to busy wait or not.
For instance, interlocked list operations are very useful, since they do not require any mutex or spinlock acquisition.

> How can I help you ("MSphobic biases" aside)?

Sorry, you cannot help me :-)

Max

Maxim S. Shatskih

unread,
Mar 27, 2002, 7:37:23 PM3/27/02
to
> > I still have no idea what your point is other that
> > you seem to be fanatical about using pthreads.
>
> I am fanatical about good/reasonable/simple/well-defined
> programming interfaces/models. Win32-threading isn't such
> one.

Usually, such claims must be proven, and not by pointing to self-glorifying texts on the web.

From the whole this thread, I cannot conclude anything on pthreads, I can only confirm my conclusion on usual Linuxoids :-)
Their usual behaviour is - "MS sux! sux! SUX! and I'm great! great! GREAT!" - usually without any real arguments.

Max

Alexander Terekhov

unread,
Mar 27, 2002, 8:05:51 PM3/27/02
to
> > How can I help you ("MSphobic biases" aside)?
>
> Sorry, you cannot help me :-)

Yes, now I see it. Forget it and "enjoy" Win32.

regards,
alexander.

Maxim S. Shatskih

unread,
Mar 27, 2002, 8:50:53 PM3/27/02
to
> Yes, now I see it. Forget it and "enjoy" Win32.

Sorry, this_coding_style_alone (used by pthreads) is enough for me to prefer Win32.
I hate press "_" extra time
:-))))

I also have strong dislike to using any sources scattered all over the web and poorly documented in any serious projects.
Surely the native OS capabilities are more trustworthy, not to say the legal reasons - can I use GPLed code in commercial software?
I also hate stupid wrappers - and "pthreads over Win32" seems to be a stupid wrapper over native Win32 threading. There is an
"Occam's Razor" principle.

Maybe "pthreads over Win32" can be useful to write the code which must be portable between Win32 and UNIXen - but for now I have no
such projects.

Win32 has its drawbacks (USER, for instance), but they are not in threading.

Max

Patrick TJ McPhee

unread,
Mar 27, 2002, 8:50:52 PM3/27/02
to
In article <MPG.170b8ff43...@news.direcpc.com>,
Jerry Coffin <jco...@taeus.com> wrote:

% doesn't support cancellation "correctly", POSIX doesn't support
% suspended threads (for only one example) "correctly".

But suspending a thread is roughly equivalent to asynchronously terminating
a thread when it comes to introducing instability.
--

Patrick TJ McPhee
East York Canada
pt...@interlog.com

Patrick TJ McPhee

unread,
Mar 27, 2002, 9:14:11 PM3/27/02
to
[note the follow-ups are set to comp.programming.threads]


In article <a7tnra$ic0$1...@gavrilo.mtu.ru>,
Maxim S. Shatskih <ma...@storagecraft.com> wrote:

[about condition variables]

% Thanks. I have heard of them from one UNIX guy, a terrifying inconvinient
% thing.

That's an odd statement. CVs are a fairly light-weight signalling
mechanism. They're not semaphores, so they're not the right thing to
use if you need a semaphore, but if you want to wait for some arbitrary
condition to become true, they're really quite convenient.

Alexander Terekhov

unread,
Mar 27, 2002, 9:19:28 PM3/27/02
to
"Maxim S. Shatskih" wrote:
>
> > > I still have no idea what your point is other that
> > > you seem to be fanatical about using pthreads.
> >
> > I am fanatical about good/reasonable/simple/well-defined
> > programming interfaces/models. Win32-threading isn't such
> > one.
>
> Usually, such claims must be proven, and not by pointing to self-glorifying texts on the web.

Heck! Such claims aside for a moment, could you
please define "self-glorifying texts on the web"
term for me-stupid?

> From the whole this thread, I cannot conclude anything on pthreads,

You are not supposed to "conclude anything on pthreads"
from this thread. Go and learn them, use google and
its archives (this c.p.t newsgroup, I mean), etc. Do
your own research. Think... or just stay in the total
ignorance of something NOT so ugly as Win32-threading
model and its APIs. That's all your choice.

> I can only confirm my conclusion on usual Linuxoids :-)
> Their usual behaviour is - "MS sux! sux! SUX! and I'm
> great! great! GREAT!" - usually without any real arguments.

Okay, for the record, here is one more "MS sux! sux! SUX!
and I'm great! great! GREAT!" link:

http://www.codeproject.com/interview/herbsutter3032002.asp?forumid=3455&tid=131105&select=133959#xx133959xx
(see the whole "Re:LOL" sub-thread)

but... I guess that most likely (given the "abilities"
you have demonstrated so far in this silly thread), you
won't be able to find "any real arguments" there too. ;-)

regards,
alexander.

Alexander Terekhov

unread,
Mar 27, 2002, 9:47:43 PM3/27/02
to

"Maxim S. Shatskih" wrote:
[...]

> Surely the native OS capabilities are more trustworthy,
> not to say the legal reasons - can I use GPLed code in
> commercial software?

Ever heard of *L*GPL (GNU *Lesser* General Public License)?

[...]


> Maybe "pthreads over Win32" can be useful to write the
> code which must be portable between Win32 and UNIXen

http://sources.redhat.com/pthreads-win32
(see "COPYING" in CVS)

"Although pthreads-win32 makes it possible for applications
that use POSIX threads to be ported to Win32 platforms, the
broader goal of the project is to encourage the use of open
standards, and in particular, to make it just a little easier
for developers writing Win32 applications to consider
widening the potential market for their products"

regards,
alexander.

Patrick TJ McPhee

unread,
Mar 27, 2002, 9:48:38 PM3/27/02
to
[note follow-up to comp.programming.threads]

In article <a7sn0m$2jpp$1...@gavrilo.mtu.ru>,


Maxim S. Shatskih <ma...@storagecraft.com> wrote:

% What is thread cancellation?
% Is it the ability of sending a SIGINT-like signal to a thread, which
% will interrupt it, force it to execute some rundown code and
% quit?
%
% If yes - this is an extremely dangerous thing, at least as dangerous as
% TerminateThread.

Cancellation is TerminateThread designed properly. The programmer can
choose whether a thread accepts cancellation requests or not, and whether
they should be acted on immediately (asynchronous cancellation) or at
one of a well-defined set of function calls (deferred cancellation).
If I've understood this thread correctly, asynchronous thread cancellation
is slightly less dangerous than TerminateThread, and should only be
enabled for highly CPU-intensive threads which don't allocate any
resources. Deferred threads provide a reliable clean-up mechanism so
that a cancelled thread _can_ be guaranteed not to have any resource
leaks.

Posix deferred cancellation is essentially advice to the target thread
to go away and stop bothering people, along with a mechanism to
interrupt system calls so the target thread can take that advice
promptly. I'm not sure that it requires kernel support, but it
does need the C library to check for the cancellation request at
the appropriate moments.

% If you're not satisfied with it - write a C++ class for a thread which
% will encapsulate the shutdown event (or the shutdown flag) in
% it.

Very much in the posix spirit.

Alexander Terekhov

unread,
Mar 27, 2002, 10:33:58 PM3/27/02
to

Patrick TJ McPhee wrote:
>
> [note follow-up to comp.programming.threads]
>
> In article <a7sn0m$2jpp$1...@gavrilo.mtu.ru>,
> Maxim S. Shatskih <ma...@storagecraft.com> wrote:
>
> % What is thread cancellation?
> % Is it the ability of sending a SIGINT-like signal to a thread, which
> % will interrupt it, force it to execute some rundown code and
> % quit?
> %
> % If yes - this is an extremely dangerous thing, at least as dangerous as
> % TerminateThread.
>
> Cancellation is TerminateThread designed properly. The programmer can
> choose whether a thread accepts cancellation requests or not, and whether
> they should be acted on immediately (asynchronous cancellation) or at
> one of a well-defined set of function calls (deferred cancellation).
> If I've understood this thread correctly, asynchronous thread cancellation
> is slightly less dangerous than TerminateThread, and should only be
> enabled for highly CPU-intensive threads which don't allocate any
> resources.

and/or modify some shared data and/or do something else
which isn't *async-cancel-safe*. Such async-cancel-regions
are formed using pthread_setcanceltype() call. Another
pthread call -- pthread_setcancelstate() is used to
control cancelability too: ENABLED/DISABLED (enabled
is the default). In C++, cancel (and thread exit) is
just an exception causing C++ stack-unwinding raised
by cancel.points or from async-cancel-regions (at any
point inside them).

regards,
alexander.

Maxim S. Shatskih

unread,
Mar 28, 2002, 3:26:34 AM3/28/02
to
> resources. Deferred threads provide a reliable clean-up mechanism so
> that a cancelled thread _can_ be guaranteed not to have any resource
> leaks.

Rundown routines are reliable only on paper, coding such things are extremely bug-prone.

> interrupt system calls so the target thread can take that advice
> promptly. I'm not sure that it requires kernel support, but it

Interrupting syscalls requires the kernel support for sure, and NT kernel does support it (FILE_SYNCHRONOUS_IO_ALERT and such),
though IIRC Win32 does not.

Max

Alexander Terekhov

unread,
Mar 28, 2002, 7:19:27 AM3/28/02
to

"Maxim S. Shatskih" wrote:
>
> > resources. Deferred threads provide a reliable clean-up mechanism so
> > that a cancelled thread _can_ be guaranteed not to have any resource
> > leaks.
>
> Rundown routines are reliable only on paper, coding such things are extremely bug-prone.

Ever heard of *exception-safety*, Maxim?

Here is a couple of links (to papers
on "reliability/exceptions")) for you:

http://www.bleading-edge.com/Publications/C++Report/v9603/Article2a.htm
http://www.bleading-edge.com/Publications/C++Report/v9605/Column1.htm
http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
http://www.boost.org/more/generic_exception_safety.html
http://www.gotw.ca

And, please, keep your mouth closed until at least
you've done with that basic stuff for the "modern"
programmers.

regards,
alexander.

P.S. Given your "mtu.ru" server address
(organization used to be full of *clever*
and *committed* people (NOT dilettantes/
amateurs) a couple of years ago, at least)
and your "kernel" programming interests,
I'm going to recommend to you AGAIN that
you better click on the 2nd link below:

http://groups.google.com/groups?as_umsgid=3CA20486.867A6B3E%40web.de

"> As about NT kernel events - they are really great,

I don't really care much about "kernel" internal stuff, however:

> since they can be created anywhere - even on stack - without


bothering to
> allocate them in some special way.

> Linux kernel also has the "waitqueue" object which is nearly the same
as NT's KEVENT.

http://users.footprints.net/~kaz/lmc.html

"Home of LMC

LMC stands for Linux Mutexes and Conditions. It is a small C

header file and source file which implements these mutual
exclusion and synchronization primitives to be used in
Linux kernel programming. It comes with a brief white
paper that explains why these things are useful, and how
they are used. ...""

AND *READ* THAT BRIEF PAPER WRITTEN BY KAZ, HECK!

Jos Scherders

unread,
Mar 28, 2002, 4:23:35 PM3/28/02
to
> From the whole this thread, I cannot conclude anything on pthreads, I can
only confirm my conclusion on usual Linuxoids :-)
> Their usual behaviour is - "MS sux! sux! SUX! and I'm great! great!
GREAT!" - usually without any real arguments.
>
> Max

Agreeing with Max. Can't we ban this guys from this list. I am fed up with
this pointless discussion. Uh, what discussion ? I haven't seen one decent
argument in favor of anything, including pthreads.

Jos.

Alexander Terekhov

unread,
Mar 28, 2002, 5:36:52 PM3/28/02
to

Jos Scherders wrote:
>
> > From the whole this thread, I cannot conclude anything on pthreads, I can
> only confirm my conclusion on usual Linuxoids :-)
> > Their usual behaviour is - "MS sux! sux! SUX! and I'm great! great!
> GREAT!" - usually without any real arguments.
> >
> > Max
>
> Agreeing with Max. Can't we ban this guys from this list.

http://www.faqs.org/faqs/usenet/moderated-ng-faq/index.html

> I am fed up with
> this pointless discussion. Uh, what discussion ? I haven't seen one decent
> argument in favor of anything, including pthreads.

http://groups.google.com/groups?group=sci.med.vision

regards,
alexander.

Jonathan de Boyne Pollard

unread,
Mar 27, 2002, 4:19:26 PM3/27/02
to
AT> "The best approach to terminate threads gracefully is ...."
AT> THIS:
AT> http://sources.redhat.com/pthreads-win32

However, its condition variable implementation should be avoided if one
can guarantee that one is using Windows NT and not DOS-Windows.

Alexander Terekhov

unread,
Mar 30, 2002, 10:12:41 AM3/30/02
to

Uhmm. Interesting. Could you please elaborate?

regards,
alexander.

Jonathan de Boyne Pollard

unread,
May 12, 2002, 3:19:25 PM5/12/02
to
AT> "The best approach to terminate threads gracefully is ...."
AT> THIS:
AT> http://sources.redhat.com/pthreads-win32

JdeBP> However, its condition variable implementation should be avoided if one
JdeBP> can guarantee that one is using Windows NT and not DOS-Windows.

AT> Uhmm. Interesting. Could you please elaborate?

If one can guarantee that one is using Windows NT and not DOS-Windows,
then many design constraints on a Win32 program disappear. Most notably
in this particular case, the principal (and pretty much only) reason for
not having a simple condition variable implementation, the lack of
SignalObjectAndWait() on DOS-Windows, goes away.

josh

unread,
May 12, 2002, 5:40:10 PM5/12/02
to
Perhaps I'm misunderstanding the topic, but isn't the very concept of a thread
lacking on "Dos-Windows", and therefore this platform should simply be excluded
from the argument?

Gary Chanson

unread,
May 12, 2002, 11:50:47 PM5/12/02
to

"josh" <jo...@xtreme.net> wrote in message
news:1106_1021239610@adgq423gadgqdge...

> Perhaps I'm misunderstanding the topic, but isn't the very concept of a
thread
> lacking on "Dos-Windows", and therefore this platform should simply be
excluded
> from the argument?

I assume that by "Dos-Windows" he means Win9x not Win30. Win9x does
have threads but does not support SignalObjectAndWait().

--

-Gary Chanson (MVP for Windows SDK)
-gch...@TheWorld.com

-War is the last resort of the incompetent.


Alexander Terekhov

unread,
May 13, 2002, 3:15:03 AM5/13/02
to

Jonathan de Boyne Pollard wrote:
>

SignalObjectAndWait() != POSIX condition variable,
to begin with... and, BTW, given:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q173260
("PRB: Synchronization Failure When Debugging (Q173260)")

that "entire" stuff is just yet another illustration
of "total brain-damage" principle that rules at MS
location...

regards,
alexander.

P.S. < quote from the link/PRB above >

"....
RESOLUTION

Placing Sleep(0) before the PulseEvent() or
SetEvent()/ResetEvent() calls will probably"

'probably' He he. ;-)

"avoid this problem, but this is not guaranteed
either. "

Ahhh. ;-) ;-)

"Unfortunately, there is no guaranteed workaround
for this situation.
...."

That's NOT true. There IS *pretty guaranteed* ;-)
"workaround for this situation":

http://sources.redhat.com/pthreads-win32

Jonathan de Boyne Pollard

unread,
May 13, 2002, 3:54:01 AM5/13/02
to
j> [...] isn't the very concept of a thread lacking on "Dos-Windows",
j> and therefore this platform should simply be excluded from the
j> argument?

No. DOS-Windows has had threads since DOS-Windows 95.

josh

unread,
May 13, 2002, 4:58:23 AM5/13/02
to
Oh, I see. I guess I didn't consider 95 a "DOS" anything.

Slava M. Usov

unread,
May 13, 2002, 10:12:54 AM5/13/02
to
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3CDF67F7...@web.de...

[...]

> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q173260
> ("PRB: Synchronization Failure When Debugging (Q173260)")
>
> that "entire" stuff is just yet another illustration
> of "total brain-damage" principle that rules at MS
> location...

Did you read the article by keywords, such as "probably" and "no guaranteed
workaround", skipping the contents completely? If you did not notice, the
article says that while a thread is suspended, PulseEvent() will not wake
the thread, which is the intended and documented behavior:

[quoting Platform SDK]

[...] if no thread can be released immediately, PulseEvent simply sets the
event object's state to nonsignaled and returns.

[end quote]

Now how is that different from the KB article? The bottom line, PulseEvent()
works as it is advertised; that debugging is difficult is irrelevant.

S

Lucian Wischik

unread,
May 13, 2002, 11:08:20 AM5/13/02
to
[pthreads]

I love the way Windows uses events rather than condition variables! The
fact that a "Signal" on an event isn't lost even though no-one's waiting
on it (while a condition variable signal does get lost) means you don't
have to wrap your brain around that horrendous
release-mutex-then-wait-then-reacquire-mutex command. Windows signals seem
way more natural.

--
Lucian Wischik, Queens' College, Cambridge CB3 9ET. www.wischik.com/lu

Alexander Terekhov

unread,
May 13, 2002, 11:50:12 AM5/13/02
to

"Slava M. Usov" wrote:
>
> "Alexander Terekhov" <tere...@web.de> wrote in message
> news:3CDF67F7...@web.de...
>
> [...]
>
> > http://support.microsoft.com/default.aspx?scid=kb;EN-US;q173260
> > ("PRB: Synchronization Failure When Debugging (Q173260)")
> >
> > that "entire" stuff is just yet another illustration
> > of "total brain-damage" principle that rules at MS
> > location...
>
> Did you read the article by keywords, such as "probably" and "no guaranteed
> workaround", skipping the contents completely?

No; I did read it "completely".

> If you did not notice, the
> article says that while a thread is suspended, PulseEvent() will not wake
> the thread,

Not only PulseEvent. Read again.

> which is the intended and documented behavior:

*Intended* "brain-damage" is even WORSE than "accidental"
one. "Documented" is GOOD, though! ;-)

[...]


> Now how is that different from the KB article? The bottom line, PulseEvent()
> works as it is advertised; that debugging is difficult is irrelevant.

Irrelevant to what? That's exactly what makes this particular
piece of Win32 (among many others such pieces) *totally
brain-damaged*. Without that "feature", cond.vars. would be
fairly "simple" to implement/emulate (just an illustration):

http://groups.google.com/groups?as_umsgid=3AEAC433...@web.de

:>---------- Algorithm 1 ----------
:>given:
:>ex_mutex - mutex
:>cond - autoreset event
:>nWaiters - int
:>
:>wait(timeout) {
:> nWaiters++
:> bTimedOut=SignalAndWait(ex_mutex, cond, timeout)
:> lock ex_mutex
:> nWaiters--
:> return bTimedOut
:>}>
:>signal(bAll) {
:> do (bAll?nWaiters:1 times) {
:> PulseEvent(cond)
:> }
:>}
:>---------- ---------- ----------
:>This pseudocode assumes that ex_mutex is always held by the thread
calling
:>signal, ....

regards,
alexander.

Alexander Terekhov

unread,
May 13, 2002, 12:07:58 PM5/13/02
to

Lucian Wischik wrote:
>
> [pthreads]
>
> I love the way Windows uses events rather than condition variables! The
> fact that a "Signal" on an event isn't lost even though no-one's waiting
> on it (while a condition variable signal does get lost) means you don't
> have to wrap your brain around that horrendous
> release-mutex-then-wait-then-reacquire-mutex command. Windows signals seem
> way more natural.

My "usual ramblings" aside (see the beginning of that thread,
if you are interested[1] ;-)), check out this conversation
(and, please, don't miss the "coding exercise" ;-) ;-)):

http://www.codeproject.com/interview/herbsutter3032002.asp?forumid=3455&tid=131105&select=142170&fr=51#xx142170xx
(CV:"William E. Kempf" vs. EVENT:"Tim Smith" ;-))

HTH.

regards,
alexander.

P.S. Lucian, STUDY condvars (or, even better, the entire
pthreads altogether)! *You won't regret, really!*

[1]
http://www.codeproject.com/interview/herbsutter3032002.asp?forumid=3455&tid=131105&select=133959#xx133959xx

Lucian Wischik

unread,
May 13, 2002, 12:32:08 PM5/13/02
to
Alexander Terekhov <tere...@web.de> wrote:
>My "usual ramblings" aside (see the beginning of that thread,
>if you are interested[1] ;-)), check out this conversation
>(and, please, don't miss the "coding exercise" ;-) ;-)):
>P.S. Lucian, STUDY condvars (or, even better, the entire
> pthreads altogether)! *You won't regret, really!*

I am interested. I taught condvars to students. I went to work at Compaq
SRC where they came up with one of the first real implementations of
condvars, partly because of that and because of their lovely language
Modula3. Coincidentally, the project I was working on there was proving
the correctness of programs written using Win32 primitives. Your "usual
ramblings" weren't a real argument, just bluster. The thread you pointed
me to was the same.

My experience was that win32 events were easier to program with because
they avoided the horrendous brain-twists needed to get around condvars. I
experience this brain-twist when teaching condvars to students. I haven't
taught win32 events yet. But when I figured out how to program the basic
multithreaded structures with events, I loved the solutions that were
possible.

josh

unread,
May 13, 2002, 7:58:33 AM5/13/02
to
On 13 May 2002 15:08:20 GMT, ljw...@cus.cam.ac.uk (Lucian Wischik) wrote:
> [pthreads]
>
> I love the way Windows uses events rather than condition variables! The
> fact that a "Signal" on an event isn't lost even though no-one's waiting
> on it
If you PulseEvent and no one's looking, it'll be lost.

Lucian Wischik

unread,
May 13, 2002, 1:09:10 PM5/13/02
to

So use SetEvent, which won't be!

PulseEvent smells like it was designed for one particular and bizarre
situation and isn't worth using in general because you don't encounter
that exact situation.

I'd agree that the main weakness of win32 events is that it's harder to
broadcast. And maybe people were trying (misguidedly) to use PulseEvent
for a broadcast. But I've found that different design of the
multithreading works better than trying to simulate the condvar broadcast.

josh

unread,
May 13, 2002, 8:37:45 AM5/13/02
to
On 13 May 2002 17:09:10 GMT, ljw...@cus.cam.ac.uk (Lucian Wischik) wrote:
> josh <jo...@xtreme.net> wrote:
> >On 13 May 2002 15:08:20 GMT, ljw...@cus.cam.ac.uk (Lucian Wischik) wrote:
> >> I love the way Windows uses events rather than condition variables! The
> >> fact that a "Signal" on an event isn't lost even though no-one's waiting
> >> on it
> >If you PulseEvent and no one's looking, it'll be lost.
>
> So use SetEvent, which won't be!

If you use SetEvent on a manual event it'll release everyone waiting on it and
will leave the event in the "signalled" state till you ResetEvent. PulseEvent
will let go only one thread and reset the event. And in both cases if no one was
waiting, the signal occurrence will be lost.

> PulseEvent smells like it was designed for one particular and bizarre
> situation and isn't worth using in general because you don't encounter
> that exact situation.
>
> I'd agree that the main weakness of win32 events is that it's harder to
> broadcast.

Actually, I like Win32 events better than condition variables. You can broadcast
with a manual version. It's in general more straighforward to use, I think.

> And maybe people were trying (misguidedly) to use PulseEvent
> for a broadcast.

Not at all, it's there to release one thread on a manual reset event. With
pthreads you can't even guarantee such a thing, it's, unless I'm mistaken, at-
least-one thread release.

Lucian Wischik

unread,
May 13, 2002, 1:47:18 PM5/13/02
to
josh <jo...@xtreme.net> wrote:
>[So use SetEvent!]

>If you use SetEvent on a manual event it'll release everyone waiting on it and
>will leave the event in the "signalled" state till you ResetEvent...

>And in both cases if no one was waiting, the signal occurrence will be lost.

What do you mean "the signal occurrence will be lost"? The fact that it
was signalled has not been lost. So you must mean something else by
"occurence" but I don't know what.

Slava M. Usov

unread,
May 13, 2002, 2:18:29 PM5/13/02
to
"Alexander Terekhov" <tere...@web.de> wrote in message
news:3CDFE0B4...@web.de...

> Not only PulseEvent. Read again.

Yeah, right. The pair of SetEvent()/ResetEvent() which is the same thing
given the usage scenario in question.

> *Intended* "brain-damage" is even WORSE than "accidental"
> one. "Documented" is GOOD, though! ;-)

Until you show what so _intrinsically_ brain damaged there is in
PulseEvent() this is, sorry, merely hot air.

> Irrelevant to what? That's exactly what makes this particular
> piece of Win32 (among many others such pieces) *totally
> brain-damaged*. Without that "feature", cond.vars. would be
> fairly "simple" to implement/emulate (just an illustration):

Excuse me. The world is not centered around the condition vars. Some types
may find it difficult to believe, but just assume that. Now, apart from the
conditional vars, or, more specifically, from the difficulty to broadcast
with Win32 events, what is so brain-damaged about them? You're trying to use
the tool that is not fit for the job, no wonder it hurts. If you do not know
how to go about without using events, ask, repeating that "one of Win32
mechanism is not a good foundation for X, so that Win32 mechanism is brain
damaged, and, BTW, the whole Win32 is brain damaged" will get you nowhere.

S


Michael J. Saletnik

unread,
May 13, 2002, 6:20:56 PM5/13/02