Q: use CreateThread() and TerminateThread() and message procedure
JCR
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
> I use CreateThread() and TerminateThread() in a simple program.
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
>
> 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
> 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
>
> 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
>> "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?
Tim Robinson
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
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
@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
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
> 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
>
> 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
>> 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".
Davlet Panech
>
> >> 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
> 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
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
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
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
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
>
> 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
"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
"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?
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
[ ... ]
> > > 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
> 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
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
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
[ ... ]
> 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
> >
> > 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
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
> >
> > 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
> > 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
>
> Sorry, you cannot help me :-)
Yes, now I see it. Forget it and "enjoy" Win32.
regards,
alexander.
Maxim S. Shatskih
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
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.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Alexander Terekhov
>
> > > 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
"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
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.
Jos Scherders
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
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
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.