views:

683

answers:

4

Can I get a threads suspend count under Windows CE, using C or Visual C++, without calling resume or suspend functions? The only way I can see of doing it is something like

int Count = SuspendThread(ThreadHandle);  
ResumeThread(ThreadHandle);

This has a couple of problems, firstly, I'd rather not suspend the thread, and secondly the suspend might fail if the thread is running kernel code. I can work around this, but I feel there should be a more elegant solution. I could also reverse it using

int Count = ResumeThread(ThreadHandle);
SuspendThread(ThreadHandle);

But this has similar problems. Any good alternative method of getting the suspend count from the handle?

A: 

Probably with WaitForSingleObject you can check if the thread is suspended but you can not retrieve the suspend counter.

Nick D
+4  A: 

I have a combined solution. Use WaitForSingleObject() to determine if the thread is suspended or not.

If it's not suspended, the suspend count is obviously 0.

If it's suspended, it's safe to call SuspendThread() to get the suspend count. Since it's already suspended you will not stall anything.

Magnus Skog
Yep, this is the only way to do it.
ctacke
Interesting answer. How long would wait, would 1ms suffice in all cases, or is it liable to be slower?
Shane MacLaughlin
Actually I think you can use waiting time 0. WaitForSingleObject() will test the state and return immediately. You are only interested to check the return value against WAIT_OBJECT_0. Which would tell you that the thread state is signaled and therefore not suspended.
Magnus Skog
Just checked it, that work well thanks. Have a good weekend.
Shane MacLaughlin
Thanks mate. The same to you !
Magnus Skog
A: 

Even the Thread in Active you will still receive a WAIT_TIMEOUT result, this because Threads only signal when they finish, not when they're running.

That said WaitForSingleObject(hThread,INFINITE) waits until the threads finishes.

monxalo
Which is why the proposed wait was for 0, not INFINITE.
ctacke
+1  A: 

You should not suspend any thread on any platform, ever.

You should instead add synchronization points in your threading code that explicitly waits for a flag to become signaled before it is allowed to continue. This way you know where it will be paused, or at least know that it will be paused at safe points.

The following operations on threads should be banned, outright, from any platform for any programmer:

  • Suspend
  • Resume (since you don't need it if you can't suspend the thread)
  • Kill/Abort

You should never, ever, forcibly impose your will from the outside on a thread. You have no guarantee what it is doing, what kind of resources it is currently locking.

Always write threading in a cooperative mode. Your thread should be aware of its surroundings, and yield to wishes of the outside world to either exit in an orderly fashion, or pause until it can safely continue.

Lasse V. Karlsen
Similarly using INFINITE in a Wait should never, ever happen.
ctacke
I wholly agree, it's a hang waiting to happen.
Lasse V. Karlsen
+1, after much tedious debugging, I ended up removing all Suspend/Resume calls, and reducing all the sync objects to a single mutex associated with a communications stack use between the two threads in question.
Shane MacLaughlin