If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: why multithread class don't accept the precedure name?:(

You're got two problems with this code

1) show is defined as returning an int, but MyThreadProc is defined as returning void - so either show has to return void or MyThreadProc has to be defined as returning an int (I changed show to return void for my test).

2) when you pass a pointer to a function (as passing it to b.Start), you just pass the function name

Code:

b.Start(show);

All advice is offered in good faith only. You are ultimately responsible for effects of your programs and the integrity of the machines they run on.

Re: why multithread class don't accept the precedure name?:(

Originally Posted by 2kaud

You're got two problems with this code

1) show is defined as returning an int, but MyThreadProc is defined as returning void - so either show has to return void or MyThreadProc has to be defined as returning an int (I changed show to return void for my test).

2) when you pass a pointer to a function (as passing it to b.Start), you just pass the function name

Re: why multithread class don't accept the precedure name?:(

Originally Posted by Cambalinho

if 1 thread(these thread) is used, then terminate it and create another one

But how could you CloseHandle while handle is already NULL?
And how could you use TerminateThread passing in the invlid handle (it is either NULL or, at least not more valid after CloseHandle was called!)?
Besides, using TerminateThread to exit the thread is a very very wrong (or at least very poor) design. Again: read MSDN about TerminateThread and how to exit the worker thread.

Re: why multithread class don't accept the precedure name?:(

Originally Posted by VictorN

But how could you CloseHandle while handle is already NULL?
And how could you use TerminateThread passing in the invlid handle (it is either NULL or, at least not more valid after CloseHandle was called!)?
Besides, using TerminateThread to exit the thread is a very very wrong (or at least very poor) design. Again: read MSDN about TerminateThread and how to exit the worker thread.

by reading msdn information the TerminateThread is very 'dangerous'. but if is, how can i terminate a thread?
(i will see in other pages, maybe i can find something)

Re: why multithread class don't accept the precedure name?:(

Originally Posted by Cambalinho

by reading msdn information the TerminateThread is very 'dangerous'. but if is, how can i terminate a thread?
(i will see in other pages, maybe i can find something)

Thead exits itself returning some value (exit code) from its thread procedure.
To signal a thread to exit from outside the thread some Event is usually set (and thread must regularly check if the event was set or not using some of the Wait functions)

Re: why multithread class don't accept the precedure name?:(

Originally Posted by Cambalinho

by reading msdn information the TerminateThread is very 'dangerous'. but if is, how can i terminate a thread?
(i will see in other pages, maybe i can find something)

You don't force terminate a thread (except in dire emergencies!). A thread functions ends itself by returning normally. If one thread wants control over another then this is accomplished via messages, events etc. If you force terminate a thread then object destructors are not called, data isn't flushed to disk etc etc. When you start dealing with multiple threads you need to have knowledge of multi-tasking and how things are done. Just because something can be done using the available api, this doesn't mean they should be done!

No. I don't think that you have been following the advice offered on previous threads and understand multi-processing

1) Don't use CreateThread() - use _beginthreadex().

2) Don't use TerminateThread - use messages and events.

3) In MultithreadProcedure you are repeatly calling ThreadProcedure in an infinite loop until a flag is set. You wouldn't normally spin like this as it uses resources. You would use messages/events.

4) Handle_of_thread_1 is set to 0 and then used as a parameter to CloseHandle and TerminateThread??? As a mimimum, Handle_of_thread_1 should be set to hMyThread after the CreateThread function (but see 1) above).

5) You don't test that CreateThread has succeeded or failed.

6) You set bLnDestroyed to true at the start of start function and then a few lines later set it to false without being used inbetween.

7) blnDestroyed is set in one thread and tested in another. The compiler doesn't know about multi-tasking and might easily optimse the test in multithread procedure so that it loads the value once into a register and never looks at the actual value again. So blnDestroyed could be set to true yet the test still fail. This is where criticalsections and the interlocked family of functions come in. As a minumum, blnDestroyed should be defined as volatile.

All advice is offered in good faith only. You are ultimately responsible for effects of your programs and the integrity of the machines they run on.

No. I don't think that you have been following the advice offered on previous threads and understand multi-processing

1) Don't use CreateThread() - use _beginthreadex().

2) Don't use TerminateThread - use messages and events.

3) In MultithreadProcedure you are repeatly calling ThreadProcedure in an infinite loop until a flag is set. You wouldn't normally spin like this as it uses resources. You would use messages/events.

4) Handle_of_thread_1 is set to 0 and then used as a parameter to CloseHandle and TerminateThread??? As a mimimum, Handle_of_thread_1 should be set to hMyThread after the CreateThread function (but see 1) above).

5) You don't test that CreateThread has succeeded or failed.

6) You set bLnDestroyed to true at the start of start function and then a few lines later set it to false without being used inbetween.

7) blnDestroyed is set in one thread and tested in another. The compiler doesn't know about multi-tasking and might easily optimse the test in multithread procedure so that it loads the value once into a register and never looks at the actual value again. So blnDestroyed could be set to true yet the test still fail. This is where criticalsections and the interlocked family of functions come in. As a minumum, blnDestroyed should be defined as volatile.

Something, it's always something. Something that you need to learn by reading trustworthy sources like MSDN and books written by recognized technical writers. E.g. Richter, or Johnson M. Hart. There you'll find the answers why not to use TerminateThread, or what is the difference between bare CreateThread and runtime _beginthreadex, as well as lots of other details. But by no means you should learn complex technical topics by just asking on public forums.