Thread Safety in C++ code

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I was going through this article
http://blogs.msdn.com/oldnewthing/archive/2004/03/08/85901.aspx
This talks about "C++ scoped static initialization is not thread-safe, on
purpose!"
One of the resolutions is to use to critical section to avoid race condition.
My question is what if in any program, critical section itself is static,
then there will be thread safety issue, any pointers/ideas how avoid this
condition?

Thanks!
 
SQL_Learner said:
I was going through this article
http://blogs.msdn.com/oldnewthing/archive/2004/03/08/85901.aspx
This talks about "C++ scoped static initialization is not thread-safe, on
purpose!"
One of the resolutions is to use to critical section to avoid race
condition.
My question is what if in any program, critical section itself is static,
then there will be thread safety issue, any pointers/ideas how avoid this
condition?
Click to expand...

In order to synchronize between threads, a single critical section must be
shared between them. It's a wise strategy to initialize the shared critical
section before you start any subsequent threads. Then there is no issue.

Regards,
Will
 
In order to synchronize between threads, a single critical section must be
shared between them. It's a wise strategy to initialize the shared critical
section before you start any subsequent threads. Then there is no issue.

Regards,
Will
Click to expand...

Hi Will,

Thanks for your response. I am little unclear about the shared critical
section. My actual problem is I have a block of code which has a critical
section which is declared as static and this looks like a probable thread
safety issue as this might create 2 copies of critical sections. I am
looking for a alternative way to avoid this.

Thanks
 
SQL_Learner said:
Thanks for your response.
Click to expand...

You are welcome.
I am little unclear about the shared critical section. My actual
problem is I have a block of code which has a critical
section which is declared as static and this looks like
a probable thread safety issue as this might create 2 copies
of critical sections. I am looking for a alternative way to avoid this.
Click to expand...

You'll have to show a _little_ code.

Regards,
Will
 
You are welcome.


You'll have to show a _little_ code.

Regards,
Will
Click to expand...
Hi Will,

Here is the function
CKey* CKey::GetKey(void)
{
if (g_Key == NULL)
{
static CriticalSection cs(L"CKey::GetKey");

AutoLock lock(cs);
if ( g_Key == NULL)
{
static CKey key;
g_Key = &key;
}
}
return g_Key;
}

Here I already have a Critical Section initialized as static. I want to
rewrite this to handle the race conditions.

Thanks
 
SQL_Learner said:
Here is the function
CKey* CKey::GetKey(void)
{
if (g_Key == NULL)
{
static CriticalSection cs(L"CKey::GetKey");

AutoLock lock(cs);
if ( g_Key == NULL)
{
static CKey key;
g_Key = &key;
}
}
return g_Key;
}

Here I already have a Critical Section initialized as static. I want to
rewrite this to handle the race conditions.
Click to expand...

Oh, sorry. Judging by the name I guess you are using MFC or ATL, neither of
which is my forte (I much prefer the API)

Assuming that the constructor for the class initializes it, then what you
probably do is move it outside of any function. I could be wrong. If no one
pops in here with more definitive information you can post again in an MFC
or ATL group.

Regards,
Will
 
Here is the function
CKey* CKey::GetKey(void)
{
if (g_Key == NULL)
{
static CriticalSection cs(L"CKey::GetKey");

AutoLock lock(cs);
if ( g_Key == NULL)
{
static CKey key;
g_Key = &key;
}
}
return g_Key;
}

Here I already have a Critical Section initialized as static. I want to
rewrite this to handle the race conditions.
Click to expand...

You do have a race condition for the initialization of cs, and as Will
said, one way to fix it is to make it a global variable. (Just don't call
GetKey during initialization of some other global that is declared before
cs or in another translation unit.) Then you're just left with the issues
inherent to the "Double-Checked Locking Pattern", which you can Google for
details.
 
Thanks all fro your replies.

Yes, I moved the Critical Section into global scope to avoid race condition
and I am making sure that this global is initialized only once.
 
Back
Top