Read the problem carefully first.
There is a worker thread which gets spawned from a CreateInstance of CTest class. Here is the prototype of the class. hThread is the handle to thread and hEventShutdown is the event used to shutdown thread when program exits. WaitForShutdown is the public function which is used to signal hEventShutdown and wait on handle to thread till thread exits gracefully. WaitForShutdown is invoked from Exit of Application.
//pseudocode
CTest
{
public:
CTest* CreateInstance();
static threadproc(void *pv);
void WaitForShutdown();
public:
HANDLE hThread;
HANDLE hEventShutdown;
}
void CTest::CTest* CreateInstance()
{
// spawn a thread, pass 'this' pointer to thread , use beginthreadex
hThread = beginthreadex ( threadproc, this );
}
unsigned int CTest::threadproc( void *pv)
{
Ctest *ptest = (Ctest*)pv;
do
{
HANDLES hArray[2] = { pv->hEventShutdown, someotherhandle }
dwResult = Waitformultipleobjects( hArrary , 2);
if ( dwResult == WAIT_OBJECT_0)
delete pTest; // since it is allocated dynamically ( This is required due to some known reasons in my code)
if(dwResult == WAIT_OBJECT_0 + 1)
Doprocessing(); //DoProcessing when other thread signal someotherhandle
}while (1)
void CTest::WaitForShutdown()
{
SetEvent ( hEventShutdown);
WaitForSingleObject ( hThread,INFINITE);
}
void CTest::~CTest()
{
Closehandle(hThread)
Closehandle(hEventShutdown);
}
Now if you look at the code carefully, you will find that event is signaled from WaitForShutdown function, thread comes out of WaitForMultipleOjbects and deletes pointer of CTest. It means destructor of CTest is invoked which will obviously close thread handle ( hThread). But WaitForSingleObject from WaitForShutdown is actually waiting on thread handle. So here behavior will be undefined ( I think so, you can correct me if I am wrong). Another problem is destructor of Ctest is invoked when WaitForSingleObject is waiting on its member hThread which is not correct. I can not remove delete pTest from thread since it has to be there due to some reasons.
How will you suggest the solution to the above ?
Couple of Solution which I can think of :
I can keep thread handle in another map but I dont want to do it.
I can copy thread handle to some local variable before WaitForSingleObject in WaitForShutdown and will wait on it. Don;t know is it right ? you tell me.
Or I will use Duplicatehandle API to get reference of existing thread handle before WaitForSingleObject and wait on it. Dont know is it correct. Dont know if will the duplicate handle be alive after CloseHandle on original.
I will keep thread ID, get thread handle from thread ID and keep waiting on thread handle in WaitForShutdown. This looks more elegant but I do not know is there any way to get handle from thread id.
Correct me.
Your feedback appreciated.
The simplest way to handle this would be to simply delete the thread from WaitForShutdown, after WaitForSingleObject returns. This ensures all the handles you need - and more importantly, the object itself - remain alive to the end.
I have run this piece as is. Seems it works, and it doesn't crash.
Strangely that we can call CloseHandle(hthread), before we go out of WaitforSingleObject(hThread,INFINITE).
Of course, "academic" way to join thread is firstly WaitForSingleObject(hThread,INFINITE) than CloseHandle(hThread). So that is my suggestion - do in this way.
I don't have to add anymore.
Related
In the following example(not all the code included just the necessary portions):
class A
{
public:
void FlushToDisk(char* pData, unsigned int uiSize)
{
char* pTmp = new char[uiSize];
memcpy(pTmp, pData, uiSize);
m_Thread = boost::thread(&CSimSwcFastsimExporter::WriteToDisk, this, pTmp, uiSize);
}
void WriteToDisk(char* pData, unsigned int uiSize)
{
m_Mtx.lock();
m_ExportFile.write(pData, uiSize);
delete[] pData;
m_Mtx.unlock();
}
boost::thread m_Thread;
boost::mutex m_Mtx
}
is it safe to use the m_Thread that way since the FlushToDisk method can be called while the created thread is executing the WriteToDisk method.
Or should I do something like:
m_Thread.join();
m_Thread = boost::thread(&CSimSwcFastsimExporter::WriteToDisk, this, pTmp, uiSize);
Would this second solution be slower than the first?
From what i saw at http://www.boost.org/doc/libs/1_59_0/doc/html/thread/thread_management.html#thread.thread_management.tutorial
"When the boost::thread object that represents a thread of execution is destroyed the thread becomes detached. Once a thread is detached, it will continue executing until the invocation of the function or callable object supplied on construction has completed, or the program is terminated".
So in my case the threads should not be interrupted or?
Thanks in advance.
The second solution will pause the main thread to wait until the writer thread completes. You would be able to remove mutex if you go this way. You are guaranteed to have one file writing thread.
The first solution is going to allow main thread to continue, and will create an uncontrolled writing thread - serialized on the mutex. While you might believe this is better (main thread will not wait) I do not like this solution for several reasons.
First, you do not have any control over the number of created threads. If the function is called often, and the operation is slow, you can easily run out of threads! Second, and much more important, you will accumulate a backlog of detached threads waiting on mutex. If your main application decides to exit, all those threads will be silently killed and the updates will be lost.
In my Windows service application I may resort to calling TerminateThread API on some of the threads in my process. (Note that I do so only as a last resort measure when a thread fails to quit in a "normal fashion" using signaling mechanism and thread synchronization techniques.) What I've noticed in the event log submitted by a customer is that very rarely TerminateThread may throw the STATUS_INVALID_THREAD exception, which happens only when that API is called on a thread belonging to a threadpool.
Since I know for sure that none of my threads are started from a threadpool, the thread that my call to TerminateThread attempts to close must be coming from another process. This could happen only due to a race condition where my thread handle is closed first and then is passed again to the TerminateThread API while the OS reuses it for some other thread in another process.
So my question is, since my service is running with sufficiently high privileges (as localService) can TerminateThread API in this situation inadvertently terminate some thread belonging to another process? And if yes, how can I prevent this (apart from finding the race-condition, that I'm doing now)?
Let's let the docs speak for themselves:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686717(v=vs.85).aspx
Do not use TerminateThread():
TerminateThread is a dangerous function that should only be used in the most extreme cases. You should call TerminateThread only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination. For example, TerminateThread can result in the following problems:
[...]
You can terminate any thread, as long as you have a handle with sufficient privileges:
A thread cannot protect itself against TerminateThread, other than by controlling access to its handles. The thread handle returned by the CreateThread and CreateProcess functions has THREAD_TERMINATE access, so any caller holding one of these handles can terminate your thread.
Note that I do so only as a last resort measure when a thread fails to quit in a "normal fashion" using signaling mechanism and thread synchronization techniques.
That is a case where you cannot call TerminateThread. You can only call TerminateThread if you have precise control over the thread you are terminating and its full cooperation. If the thread fails to quit in the normal fashion, then you have lost control over the thread, the very opposite of the required conditions under which you can call TerminateThread.
If a process has lost control over one of its threads, the process cannot be saved. This is a fundamental property of threads -- they do not provide isolation of anything but flow control.
If you must do this you can do it like this.
All you need to start is the thread handle.
You call the first function with thread handle as input using the "undocumented" NtQueryInformationThread() function with the ThreadQuerySetWin32StartAddress argument, you get the StartAddress of the thread. More reading # NTInternals.
It calls NTQueryInformationThread by function address after getting the address via GetProcAddress. Then it calls it with the ThreadQuerySetWin32StartAddress argument, getting the StartAddress of the thread.
Then you call the second function which loops through all the threads via CreateToolHelp32Snapshot and compares against the supplied StartAddress. It calls TerminateThread once it finds it.
enum THREADINFOCLASS
{
ThreadQuerySetWin32StartAddress = 9,
};
typedef NTSTATUS(__stdcall * f_NtQueryInformationThread)(HANDLE, THREADINFOCLASS, void*, ULONG_PTR, ULONG_PTR*);
ULONG_PTR GetThreadStartAddress(HANDLE hThread)
{
auto NtQueryInformationThread = reinterpret_cast<f_NtQueryInformationThread>(GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtQueryInformationThread"));
if (!NtQueryInformationThread)
return 0;
ULONG_PTR ulStartAddress = 0;
NTSTATUS Ret = NtQueryInformationThread(hThread, ThreadQuerySetWin32StartAddress, &ulStartAddress, sizeof(ULONG_PTR), nullptr);
if (NT_FAIL(Ret))
return 0;
return ulStartAddress;
}
bool TerminateThreadByStartaddress(ULONG_PTR StartAddress)
{
HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);
if (hSnap == INVALID_HANDLE_VALUE)
return false;
THREADENTRY32 TE32 = { 0 };
TE32.dwSize = sizeof(THREADENTRY32);
BOOL Ret = Thread32First(hSnap, &TE32);
while (Ret)
{
HANDLE hTempThread = OpenThread(THREAD_ALL_ACCESS, FALSE, TE32.th32ThreadID);
if (!hTempThread)
{
Ret = Thread32Next(hSnap, &TE32);
continue;
}
if (StartAddress == GetThreadStartAddress(hTempThread))
{
TerminateThread(hTempThread, 0);
CloseHandle(hTempThread);
CloseHandle(hSnap);
return true;
}
CloseHandle(hTempThread);
Ret = Thread32Next(hSnap, &TE32);
}
CloseHandle(hSnap);
return false;
}
Credits to my friend Broihon, I didn't write this code but have used it before.
Use undocumented NTSYSAPI NTSTATUS NTAPI NtTerminateThread(IN HANDLE ThreadHandle, IN NTSTATUS ExitStatus); from http://undocumented.ntinternals.net where ThreadHandle is result from OpenThread MS function and ExitStatus set to whatever you want.
I used to call CreateThread() for all my threads, and WaitForMultipleObjects(), an leave the routine.
To get somewhat faster code, I'd like to do a kind of thread pool. My thread pools are sometimes created, later used multiple times, and later destroyed (ie., there is not a single pool created at the begining of the program). Each thread in my thread pool call the same routine with different parameters, the number of threads is constant, and they always need to be launched at the same time.
What I do is as follows :
DWORD WINAPI runFunction(LPVOID p) {
Thread* = (Thread*) p;
while(true) {
WaitForSingleObject(thread->awakeEvenHandle, INFINITE);
thread->run();
SetEvent(thread->SleepingEventHandle);
SuspendThread(thread->handle);
}
return 0;
}
void ExecuteThreads(std::vector<Thread*> &threads) {
HANDLE* waitingEvents = new HANDLE[threads.size()];
for (int i=0; i<threads.size(); i++) {
if (threads[i]->handle == NULL) {
threads[i]->AwakeEventHandle = CreateEvent(NULL, true, false, "Awake");
threads[i]->SleepingEventHandle = CreateEvent(NULL, true, false, "Sleeping");
threads[i]->handle = CreateThread(NULL, 0. runFunction, (void*) threads[i], CREATE_SUSPENDED, NULL);
}
ResumeThread(threads[i]->handle);
ResetEvent(threads[i]->SleepingEventHandle);
SetEvent(threads[i]->AwakeEventHandle);
waitingEvents[i] = threads[i]->SleepingEventHandle;
}
WaitForMultipleObjects( threads.size(), waitingEvents, TRUE, INFINITE);
}
My class Thread has a destructor which calls CloseHandle for the HANDLEs SleepingEventHandle and AwakeEventHandle, and for the thread handle. The function Thread::run() is pure virtual, and it's up to the coder to inherit the Thread for an actual run() implementation.
As it, the code doesn't work . One reason is that when I don't need this pool anymore, the destructors of the Threads are called, but the runFunction cannot exits and this crashes (the pointer "thread" has been destroyed but is still used the the function). There are probably many other problems with my code.
How would you do it, in a simple manner ? Is-there an easy fix ? What problems will I encounter with this code ?
Thanks!
Why do you have to deal with such low level api functions? Have a look at boost::thread and boost::thread_group. Also there is a thread pool implementation works with boost::thread.
Now if your threads work for a short period of time, your system will have remarkable overhead with creating and signaling all those threads and events. ppl Task Parallelism or tbb::task are definitely the ways to go.
I want to start a new thread from the main thread. I can't use join since I don't want to wait for the thread to exit and than resume execution.
Basically what I need is something like pthread_start(...), can't find it though.
Edit:
As all of the answers suggested create_thread should start thread the problem is that in the simple code below it doesn't work. The output of the program below is "main thread". It seems like the sub thread never executed. Any idea where I'm wrong?
compiled and run on Fedora 14 GCC version 4.5.1
void *thread_proc(void* x)
{
printf ("sub thread.\n");
pthread_exit(NULL);
}
int main()
{
pthread_t t1;
int res = pthread_create(&t1, NULL, thread_proc, NULL);
if (res)
{
printf ("error %d\n", res);
}
printf("main thread\n");
return 0;
}
The function to start the thread is pthread_create, not
pthread_join. You only use pthread_join when you are ready to wait,
and resynchronize, and if you detach the thread, there's no need to use
it at all. You can also join from a different thread.
Before exiting (either by calling exit or by returning from main),
you have to ensure that no other thread is running. One way (but not
the only) to do this is by joining with all of the threads you've
created.
the behaviour of your code depends on the scheduler; probably the main program exits before printf in the created thread has been executed. I hope simple sleep(some_seconds) at the end of the main() will cause the thread output to appear :)
the join call waits for the thread to terminate and exit.
if you want your main thread to continue its execution while the child thread is executing, don't call join: the child thread will execute concurrently with the main thread...
Just create the thread with the detached attribute set to on. To achieve this, you can either call pthread_detach after the thread has been created or pthread_attr_setdetachstate prior to its creation.
When a thread is detached, the parent thread does not have to wait for it and cannot fetch its return value.
you need to call pthread_exit in the end of man(), which will cause main to wait other thread to start and exit.
Or you can explicitly call pthread_join to wait the newly created thread
Otherwise, when main returns, the process is killed and all thread it create will be killed.
The thread starts automatically when you create it.
Don't you just need to call pthread_create?
static void *thread_body(void *argument) { /* ... */ }
int main(void) {
pthread_t thread;
pthread_create(&thread, NULL, thread_body, NULL);
/* ... */
I'm trying to write a unit test for my FileWatcher class.
FileWatcher derives from a Thread class and uses WaitForMultipleObjects to wait on two handles in its thread procedure:
The handle returned from FindFirstChangeNotification
A handle for an Event that lets me cancel the above wait.
So basically FileWatcher is waiting for whatever comes first: a file change or I tell it to stop watching.
Now, when trying to write code that tests this class I need to wait for it to start waiting.
Peusdo Code:
FileWatcher.Wait(INFINITE)
ChangeFile()
// Verify that FileWatcher works (with some other event - unimportant...)
Problem is that there's a race condition. I need to first make sure that FileWatcher has started waiting (i.e. that its thread is now blocked on WaitForMultipleObjects) before I can trigger the file change in line #2. I don't want to use Sleeps because, well, it seems hacky and is bound to give me problems when debugging.
I'm familiar with SignalObjectAndWait, but it doesn't really solve my problem, because I need it to "SignalObjectAndWaitOnMultipleObjects"...
Any ideas?
Edit
To clarify a bit, here's a simplified version of the FileWatcher class:
// Inherit from this class, override OnChange, and call Start() to turn on monitoring.
class FileChangeWatcher : public Utils::Thread
{
public:
// File must exist before constructing this instance
FileChangeWatcher(const std::string& filename);
virtual int Run();
virtual void OnChange() = 0;
};
It inherits from Thread and implements the thread function, which looks something like this (very simplified):
_changeEvent = ::FindFirstChangeNotificationW(wfn.c_str(), FALSE, FILE_NOTIFY_CHANGE_LAST_WRITE);
HANDLE events[2] = { _changeEvent, m_hStopEvent };
DWORD hWaitDone = WAIT_OBJECT_0;
while (hWaitDone == WAIT_OBJECT_0)
{
hWaitDone = ::WaitForMultipleObjects(2, events, FALSE, INFINITE);
if (hWaitDone == WAIT_OBJECT_0)
OnChange();
else
return Thread::THREAD_ABORTED;
}
return THREAD_FINISHED;
Notice that the thread function waits on two handles, one - the change notification, and the other - the "stop thread" event (inherited from Thread).
Now the code that tests this class looks like this:
class TestFileWatcher : public FileChangeWatcher
{
public:
bool Changed;
Event evtDone;
TestFileWatcher(const std::string& fname) : FileChangeWatcher(fname) { Changed = false; }
virtual void OnChange()
{
Changed = true;
evtDone.Set();
}
};
And is invoked from a CPPUnit test:
std::string tempFile = TempFilePath();
StringToFile("Hello, file", tempFile);
TestFileWatcher tfw(tempFile);
tfw.Start();
::Sleep(100); // Ugly, but we have to wait for monitor to kick in in worker thread
StringToFile("Modify me", tempFile);
tfw.evtDone.Wait(INFINITE);
CPPUNIT_ASSERT(tfw.Changed);
The idea is to get rid of that Sleep in the middle.
There's no race, you don't have to wait for the FileWatcher to enter WaitForMultipleObjects. If you perform the change before the function is called, it will simply return immediately.
Edit: I can see the race now. Why don't you move the following line
_changeEvent = ::FindFirstChangeNotificationW(/*...*/);
from the thread function to the constructor of FileChangeWatcher? That way, you can be certain that by the time the StringToFile function is called, the file is already being watched.
You should call FindFirstChangeNotification() in your watcher's constructor and store the handle that it returns for use in your thread function. This will mean that you will catch change events from the moment of construction onwards.
Once your thread has started it simply calls wait on the two handles. If a change occurred before the thread had started up then the handle that FindFirstChangeNotification() returned will be signalled already and the change will be processed. If you wish for the thread to monitor many changes then it should loop and call FindNextChangeNotification() after processing each notification.
Instead could you use a Mutex? Before a thread could access the resources it desire, it would have to lock the Mutex and unlock it for other threads that need the resource.
Call CreateEvent() to create a non-signaled event. When the watcher thread enters its main loop (or whatever), SetEvent(). Meanwhile, in FileWatcher first WaitForSingleObject() on the event, then once that returns, WFMO as you were doing before.