[Solved] How to tell which thread is calling a object?
Author
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]
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.
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.
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.
Also, if you're using MSVC, make sure you use _beginthreadex to start the thread instead of CreateThread.
Author
Thanks will try these when I get home.
And yeah, its only for debug mode, so I dont really care about the speed.
And yeah, its only for debug mode, so I dont really care about the speed.
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.
Author
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?
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?
They're different. GetCurrentThread returns a HANDLE (void *) which is a constant. GetCurrentThreadId returns a DWORD, which is not constant.
Author
Ah ok so im looking for a DWORD then. But for some reason I...
Quote:
cannot convert from 'DWORD (__stdcall *)(void)' to 'DWORD'
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement