Thread local variables
-
Hi, I am working on a project, where i see a declaration of a thread local variable as below. __declspec(thread) long g_nLock[2] = {0, 0}; And this variable is accessed with InterlockedXXX functions. My doubt is, this variable will have the global memory local to every thread. In that case, is it required to use InterlockedXXX functions to access the variable? If i change the allocation and access method of this variable using TLS APIs, do i have to take care of locking? Thanks in advance.
Selva
-
Hi, I am working on a project, where i see a declaration of a thread local variable as below. __declspec(thread) long g_nLock[2] = {0, 0}; And this variable is accessed with InterlockedXXX functions. My doubt is, this variable will have the global memory local to every thread. In that case, is it required to use InterlockedXXX functions to access the variable? If i change the allocation and access method of this variable using TLS APIs, do i have to take care of locking? Thanks in advance.
Selva
I'm not familiar with whatever the TLS API is, but if you're accessing this variable from multiple different threads directly, you have to lock it. If you want to get around this, use only one thread to change it and post signals or windows messages to that thread telling the variable to change, that way you (probably) won't get any weird conflicts.
KR
-
Hi, I am working on a project, where i see a declaration of a thread local variable as below. __declspec(thread) long g_nLock[2] = {0, 0}; And this variable is accessed with InterlockedXXX functions. My doubt is, this variable will have the global memory local to every thread. In that case, is it required to use InterlockedXXX functions to access the variable? If i change the allocation and access method of this variable using TLS APIs, do i have to take care of locking? Thanks in advance.
Selva
You are correct, each thread will have its own copy of g_nLock that no other thread can see or modify. As such, it doesn't make sense to modify it with an Interlocked*() function. The same would be true for any blob you associate with a TLS index via TlsSetValue(). Note: Be carefull using __declspec(thread) in dll's, read the MS docs (this may no longer be an issue in VS2010 ?).
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack
-
You are correct, each thread will have its own copy of g_nLock that no other thread can see or modify. As such, it doesn't make sense to modify it with an Interlocked*() function. The same would be true for any blob you associate with a TLS index via TlsSetValue(). Note: Be carefull using __declspec(thread) in dll's, read the MS docs (this may no longer be an issue in VS2010 ?).
...cmk The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying. - John Carmack