Sign in to follow this  
ZealousEngine

[Solved] How to tell which thread is calling a object?

Recommended Posts

I have a LocklessQueue class, which allows two threads to communicate to each other. The class assumes that only one thread will be writing, and only one thread will be reading from the Que. Sure there are ways to enforce this 'rule', by creating sub 'QueReader/QueWriter' classes, but im looking for a simple way to just throw a error if the Que detects two different threads trying to read/write at the same time. In otherwords, I need a way to store the handle/id of the calling thread the first time the que object is called, and compare it everytime the que is called in the future. So, how can I 'get' a handle/id of the thread thats calling a particular object/function? [Edited by - ZealousEngine on May 26, 2007 6:51:54 PM]

Share this post


Link to post
Share on other sites
It'll depend on the OS.

I think it's GetCurrentThreadId under Windows.

But that may be slow. If you're only interested into this for debugging purposes it's fine, otherwise it completely negates the purpose of lockless threads. Not so much because of performance, but because it means your design is a mess if such scenario can happen.

But it doesn't sound like a bad idea for debug builds.

As a side note, I was experimenting with thread local storage(TLS) and found that it's horribly slow, since it does thread ID look-ups (boost implementation).

So most likely doing such checks would invalidate the performance benefit of lockless threads.

Share this post


Link to post
Share on other sites
Under windows, try both GetCurrentThread and GetCurrentThreadId. I don't see why either should be slow since iirc they just look at some memory based on an address stored in a specific machine register (FS), but perhaps one does a kernel-space lookup of some kind (to convert one way or the other).

Also, if you're using MSVC, make sure you use _beginthreadex to start the thread instead of CreateThread.

Share this post


Link to post
Share on other sites
DON'T use GetCurrentThread. That returns a constant that tells the kernel to use the current thread handle. GetCurrentThreadId gets the ID from the thread environment block (FS), as he said, so it should be fast. Thread local storage is fast, at least on Windows. TLS is just an array of pointers, the array address being pointed to by the TEB for the current thread.

Share this post


Link to post
Share on other sites
Hmm.. Im not sure if this is working.. GetCurrentThreadId returns a void pointer. When I compare two void pointers from different threads, I always get the same result. Do I need to cast the void pointer? What am I looking for anyway?

Im using boost threads, and I only have a single core cpu (but that shouldnt matter).. Anyone have any idea what I might be doing wrong?

Share this post


Link to post
Share on other sites
They're different. GetCurrentThread returns a HANDLE (void *) which is a constant. GetCurrentThreadId returns a DWORD, which is not constant.

Share this post


Link to post
Share on other sites
Hmm but return types aside, it just doesnt seem to be working, check this out...


void* globalPtr;
void* globalPtr2;

void threadCall( void ) {
globalPtr2 = GetCurrentThreadId;
};


void main( void ) {


globalPtr = GetCurrentThreadId;
boost::thread thread( &threadCall );
thread.join();

if ( globalPtr != globalPtr2 ) playVictoryMusic();


}


Shouldnt the two void pointers be different? Cause on my machine they are not (no victory music :( )

Share this post


Link to post
Share on other sites
You're not calling the function. What you're obtaining is the address of the function itself.

Instead, try:

DWORD tid = GetCurrentThreadId();


That is, don't forget the parens ie. ().

Share this post


Link to post
Share on other sites
Hah! I wasnt thinking, and just assumed that GetCurrentThreadId was a global variable somewhere. Never did I think, hey that might be a function.

Cool, everything works perfect! My lockless queue is now detecting when two threads try to read/write.

Thanks everyone!

Share this post


Link to post
Share on other sites
...if there's a non-copula verb in the name, chances are extremely high that it's a function. Nothing unique to Windows or anything.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this