Results 1 to 8 of 8

Thread: Current thread checking

  1. #1

    Current thread checking

    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

  2. #2
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,245
    Blog Entries
    2

    Current thread checking

    Hi,

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

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

    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?
    :: AthenaOfDelphi :: My Blog :: My Software ::

  3. #3

    Current thread checking

    Athena, queryperformancecounter will result in a different timestamp if you are calling it on different processors for example
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  4. #4

    Current thread checking

    Quote Originally Posted by AthenaOfDelphi
    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

  5. #5
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,245
    Blog Entries
    2

    Current thread checking

    Quote Originally Posted by JSoftware
    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.
    :: AthenaOfDelphi :: My Blog :: My Software ::

  6. #6

    Current thread checking

    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

  7. #7
    PGD Community Manager AthenaOfDelphi's Avatar
    Join Date
    Dec 2004
    Location
    South Wales, UK
    Posts
    1,245
    Blog Entries
    2

    Current thread checking

    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.
    :: AthenaOfDelphi :: My Blog :: My Software ::

  8. #8

    Current thread checking

    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

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •