Thread Safety in C++ code

"SQL_Learner" <SQ********@discussions.microsoft.comwrote in message
news:66**********************************@microsof t.com...

I was going through this article
http://blogs.msdn.com/oldnewthing/ar.../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?

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

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" <SQ********@discussions.microsoft.comwrote in message
news:83**********************************@microsof t.com...

Thanks for your response.

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.

You'll have to show a _little_ code.

Regards,
Will

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.

You'll have to show a _little_ code.

Regards,
Will

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" <SQ********@discussions.microsoft.comwrote in message
news:8A**********************************@microsof t.com...

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.

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

On Tue, 10 Oct 2006 08:14:02 -0700, SQL_Learner
<SQ********@discussions.microsoft.comwrote:

>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.

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.

--
Doug Harrison
Visual C++ MVP

On Tue, 10 Oct 2006 14:02:58 -0500, Doug Harrison [MVP] wrote:

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

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.
Then you're just left with
the issues inherent to the "Double-Checked Locking Pattern"

Here is a good article on the failings of many DCLP implementations:

http://www.aristeia.com/Papers/DDJ_J...lp%20broken%22

Regards,

Andrew Marlow

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.

SQL_Learner wrote:

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.

My solution was possibly overkill. For future reference, boost has an
implementation of "call_once": http://www.boost.org/doc/html/call_once.html

Tom

Hi Tom,

The URL http://www.boost.org/doc/html/call_once.html is not working

Thanks

"Tom Widmer [VC++ MVP]" wrote:

SQL_Learner wrote:

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.

My solution was possibly overkill. For future reference, boost has an
implementation of "call_once": http://www.boost.org/doc/html/call_once.html

Tom

SQL_Learner wrote:

Hi Tom,

The URL http://www.boost.org/doc/html/call_once.html is not working

Thanks

www.boost.org seems to be down, this one may help:

http://www.boost-consulting.com/download.html