Current thread checking

[masonwheeler]

Is there any way to check which thread a current routine is running under in a multithreaded program? I want to do a check like this:

assert(CurrentlyRunningThread <> application.MainThread);

for certain routines, which due to timing issues should always be called on their own threads and not the principal thread of the program, but I'm not sure if it's possible, and if so what the syntax for it is.

Mason

[AthenaOfDelphi]

Hi,

You can do a simple check with something like this...


if (self.threadId=getCurrentThreadID) then
begin
// do your processing here
end;


That should work, but it will only really work within a descendant of TThread class as it requires the threadId property. To do it as you've suggested, you would have to obtain the main thread id during startup and store it in a global variable for later reference (I haven't been able to find a means of getting it during my very quick search just now).

I do have a question though... why is it that timing means you can only call certain routines on their own threads?

[JSoftware]

Athena, queryperformancecounter will result in a different timestamp if you are calling it on different processors for example

[masonwheeler]

To do it as you've suggested, you would have to obtain the main thread id during startup and store it in a global variable for later reference (I haven't been able to find a means of getting it during my very quick search just now).
I'll look into that. Thanks.


I do have a question though... why is it that timing means you can only call certain routines on their own threads?
Because the main game engine loop runs on the main thread. Anything that's supposed to execute over a certain amount of time (such as fade-out/fade-in effects) has to invoke the sleep() routine, and running that on the main thread will screw up the main loop.

Mason

[AthenaOfDelphi]

Athena, queryperformancecounter will result in a different timestamp if you are calling it on different processors for example

I understand the pitfalls of multi-threading, I was just wondering what Mason was actually trying to achieve in case I could offer any useful snippets of info.

You've mentioned queryPerformanceCounter, unfortunately the checks Mason is implementing will do nothing to prevent the problem you've highlighted. The only way (that I'm aware of) to prevent it is to absolutely 100% ensure that the calls always run on the same CPU by setting the threads processor affinity mask.

[masonwheeler]

Hmm... I'm kind of new to multi-threaded coding. What's this problem you're talking about and how could it affect the execution of my code?

Mason

[AthenaOfDelphi]

Hi Mason,

There are some calls that are not 100% thread safe (although, technically they are... they just aren't 100% core/CPU safe). These are mainly (as far as I'm aware) related to timing... getTickCount and queryPerformanceCounter being the two that spring to mind.

The problem is that when you make some calls to these functions, they may return different values depending on which core/CPU they are running on. So to be clear... two sequential calls on the same CPU/core should return correct results, but two sequential calls made on different CPU/core's may not.

Since it is possible, for execution of a thread to switch between different CPU/core's during normal operation, this problem could bite you in the ass.

[masonwheeler]

Ah. OK, different sort of "timing". Not an issue here, but thanks for making me aware of it in case I need to know later on. :)

Mason